Home / The model / The capabilities / write.repository.tenant
write.repository.tenant
Push to a code host (any branch it can reach). Its effect is with-effort: undone at a cost.
What this id is made of
This is not a string. It is write.repository.tenant, three nodes joined by three edges, and each of them has an address, a page and a JSON file. Follow any of them and you get the query for that word rather than a definition of it.
| Node | Edge | Reads as |
|---|---|---|
write | has_verb | this capability has the verb write |
repository | acts_on | this capability acts on repository |
tenant | reaches | this capability reaches tenant |
code | in_family | this capability is in the code family |
with-effort | has_undo_class | this capability has the undo class with-effort |
The gloss above is a convenience, not the definition. A node carries no inherent meaning: what
write.repository.tenant is emerges from the edges traceable from it. The strongest case is tenant, where the deployment shapes that use it do not agree about what it means, and the page keeps the disagreement rather than averaging it.In 4 of 17 published shapes
| Deployment shape | Barrier there | Known by | Whose material | Note | |
|---|---|---|---|---|---|
| ◐ | Claude Code on the web (a remote session container) | setting (not a control) | observed | not stated | the attached repository only (any branch it can reach); branch discipline is the clone's hooks, a setting; no rule at the host |
| ◉ | Claude Code (the CLI, on your own machine) | expectation (not a control) | derived | not stated | |
| ◉ | Claude Code (the CLI, on your own machine) | expectation (not a control) | derived | not stated | |
| ○ | Claude (in the browser, with connectors switched on) | boundary | derived | not stated | a code-host connector |
| Barrier | What stands in the way | Is it a control | |
|---|---|---|---|
| ● | none | nothing in the way | no |
| ◉ | expectation | a rule in prose, enforced by nobody | no |
| ◐ | setting | a switch the agent's own account can flip | no |
| ○ | boundary | enforced above the grant, out of the agent's reach | yes |
What the starting mandates say about it
| The mandate says | Which mandates |
|---|---|
| authorised | A coding assistant in a container on the web, A CI job on a hosted runner |
| refused | Chat, with connectors switched on, Chat in the browser, nothing connected |
| unstated | A coding assistant on my machine, The desktop app, with local tools switched on, A browser extension I installed, A scheduled job under a service account, A reader on my mailbox, Find things in the inbox, draft replies, never send, A reader on my drive, Search our tenant, read-only, Find and read my files, An assistant over my Workspace, reading, A sandbox: build and run one AI-agent workflow, What the agent inferred it was authorised to do, from one session |
Unstated is not authorised. A mandate that never mentioned a capability did not authorise it, and the delta on every example page counts it as excess and says which kind it was.
What would move it to the fourth barrier
| What | What it costs | The barrier afterwards |
|---|---|---|
| a branch protection rule at the host - the agent cannot edit it - and a pre-push hook in the clone for the earlier, cheaper refusal | minutes; and a review step before anything deploys | boundary (host rule) · setting (hook) |
This is a published reduction, not a recommendation. Whether it is worth doing depends on the assets and the consequences, which are not in this document and are not this site's to guess. Since v0.4.3 it is also a node,
setting/write.repository.tenant, in the deployment shape universe: it narrows this capability and moves it to the barrier named in the third column, which is the path the prohibitions table's last column is a projection of.