The console's read-only claim is derived from scope, which #563 established does not mean 'does not mutate'

[serge-ivo]

The console tells an auditor "nothing can change anything" from a field that does not mean that

store/console/src/lib/toolPolicy.ts:106:

export function writesOwnData(policy: readonly ToolPolicyEntry[]): boolean {
	return listedTools(policy).some((t) => t.scope === "write" && !t.connector);
}

and :77:

export function mayWrite(t: ToolPolicyEntry): boolean {
	return t.scope === "write" || t.writeConsent === "per_call";
}

writesOwnData decides which sentence toolScopeSummary renders above the tool switches —
including the read-only claim that :116's own comment calls "the one #525 made dangerous."

#563 established what scope actually is: the write-consent trigger, not a mutation label.
FIRST_PARTY_TOOLS omit it and instance-tool-policy.ts defaults it to "read", so nine
mutating tools — start_work, stop_work, end_coding_session, set_behaviour,
set_stats_card, run_pipeline, record_feedback, create_ticket, dedupe_upsert — report
scope: "read" with no connector. writesOwnData cannot see any of them.

Why nobody has seen it

BASE always contains write_memory, which is scope:"write" with no connector, so the
predicate is true for every agent and the wrong sentence never renders. The claim is correct
today because of an invariant that exists for unrelated reasons and is declared nowhere as
load-bearing. Remove write_memory from BASE, or ship an agent that declares its tools without
it, and a Coder holding start_work and run_pipeline is described to its owner as unable to
change anything.

What changed that makes this fixable

#563 shipped a mutates field on the listing precisely because scope could not answer this
question — 104 rows, 52 mutates:true, measured in production. writesOwnData is asking the
mutates question and reading the scope field.

mayWrite is a separate call and should be looked at, not assumed: its own comment argues
scope plus per_call is right for the connector-grant decision, because http_request is
scope:"read" yet the caller names the method. That reasoning may survive mutates intact.
Decide it explicitly rather than changing both because they sit together.

Acceptance criteria

1. writesOwnData derives from mutates, or a recorded reason why scope is correct there.
2. mayWrite is decided separately and the decision stated — its existing comment is a real
   argument and must be answered, not overwritten.
3. A test pins the case that is currently masked: a policy containing a mutates:true,
   scope:"read", connector-less tool and no write_memory renders the "can change things"
   sentence. It must fail on today's code.
4. The BASE-contains-write_memory dependency is either removed or declared where it is
   relied on, so the next person does not rediscover it as a bug.

Verified vs inferred

• Verified: both function bodies and line numbers; toolScopeSummary's use of
  writesOwnData; the nine mis-scoped tools and the ?? "read" default (list_instance_tools reports nine mutating tools as scope: "read" — one field carries two incompatible meanings, and its sibling deliberately fails the other way #563); the 104/52
  production measurement; write_memory's presence in BASE.
• Inferred: that no agent today lacks write_memory — inspection of BASE, not an
  enumeration of every shipped agent's resolved tool set. If one does, this is observed rather
  than latent and should be re-rated.

[serge-ivo]

The enumeration the issue asked for — rating confirmed, and it is stronger than "latent"

Verdict: ready. The Inferred note ("that no agent today lacks write_memory — inspection of
BASE, not an enumeration") is now an enumeration, and the answer is that no agent can lack it.

Measured

GET /v1/instances/:id/tools on the deployed API, 2026-08-15, for all 34 instances on the
operator account (12 distinct agent shapes: coder, coder-repo, coder-lead, tmux-coder,
tmux-operator, iterm/kitty/terminal-operator, repo-chat, local-repo-chat, mcp-client,
job-application-assistant, small-business-website-lead-finder, and the FULL-default chat agents),
with writesOwnData / writeConnectors / toolScopeSummary recomputed exactly as the console does:

• 0 of 34 render the read-only sentence. 24 render the connector sentence, 10 the own-data one.
• Every instance lists write_memory as {scope:"write", connector:null}, so the predicate is true
  everywhere.

It is not an accident of which agents shipped — it is structural

toolNamesFor starts every branch from BASE (workers/api/src/agent-do-tools.ts:214
declared-allowlist, :218 repo, :220 coding, :222 FULL), so a declared capabilities.tools
allowlist cannot remove it — repo-chat, which declares exactly three tools, still lists all of
BASE. So the wrong sentence is unreachable today by any declaration, not merely unreached.

Two corrections that belong in the ticket:

1. The load-bearing invariant is six tools, not one. Every listing measured carries six
   connector-less scope:"write" BASE tools: write_memory, delete_memory, create_task,
   update_task, configure_board, set_user_preference (agent-do-tools.ts:74-88). AC 4 —
   "the BASE-contains-write_memory dependency is either removed or declared" — should name the
   set, or a future change that removes only write_memory will look like it broke the invariant
   when it has not.

2. The owner's off-switch does not defeat it either. This looked like the one live path to the
   read-only sentence, so I checked it: listedTools is allowed || disabled
   (store/console/src/lib/toolPolicy.ts:63-65), so a tool the owner switches off is still listed
   and still counted. Switching write_memory off does not flip the sentence. Worth recording
   so the next reader does not re-derive it.

What the enumeration did turn up — filed as #584, not folded in here

The same eight-line file renders a different sentence that is wrong on screen today:
10 of the 34 instances are told they have "no tool that reaches outside the platform" while
fetch_url is allowed:true on all ten ({scope:"read", mutates:true, connector:null, tier:"base"}, and it takes a caller-chosen method — workers/api/src/lib/tools.ts:368-376).
writeConnectors uses "names a connector" as the proxy for "reaches outside", which #525 made false
when it added the connector-less built-ins.

This matters for #577's fix, not just as a neighbour: deriving writesOwnData from mutates
(AC 1) would move fetch_url (mutates:true) into the own-data set and leave that clause exactly
as false. Two mechanisms, one function; keep #577 scoped to the read-only claim and let #584 own the
external one, or whoever picks up the second will be rewriting the first.

On the acceptance criteria as written

They are testable. AC 3 ("a policy containing a mutates:true, scope:"read", connector-less tool
and no write_memory renders the can-change-things sentence") is only reachable in a synthetic
fixture — the enumeration above shows no real instance can produce that policy — which is correct
for a latent defect, but say so in the test, or someone will hunt for the live instance that
reproduces it. mayWrite (AC 2) is untouched by any of this: its http_request argument holds
independently of the six-tool invariant.

Verified vs inferred

• Verified: the 34-instance enumeration and its 0/24/10 split, measured against the deployed API,
  not against a fixture; BASE in all four branches of toolNamesFor; the six connector-less write
  tools present on every listing; listedTools's allowed || disabled; that toolScopeSummary
  renders at store/console/src/components/ToolPermissions.tsx:123.
• Inferred: nothing load-bearing. This is one account's 34 instances — it covers every shipped
  first-party agent shape, but the structural argument (BASE in every branch), not the sample, is
  what makes the rating safe.

[serge-ivo]

Fixed in 31194df, together with #584 — all four ACs, and the collision resolved rather than deferred

Landed as one commit with #584. Keeping them apart was not possible: deriving writesOwnData from
mutates moves fetch_url (mutates:true) into the own-data set and leaves #584's clause false in
the same eight lines, which is exactly what the comment above predicted. So the underlying question
was answered once — what does "reaches outside the platform" actually mean — and both clauses now
derive from it.

AC1 — writesOwnData derives from mutates. Met.

export function writesOwnData(policy: readonly ToolPolicyEntry[]): boolean {
	return listedTools(policy).some((t) => changesAnything(t) && t.reach === "platform");
}

Note what happened to the other half of the old predicate. !t.connector was not dropped, it was
replaced by the fact it was standing in for: "has no connector" meant "stays on the platform",
and that is now reach === "platform" (a new server-sent field, workers/api/src/lib/tool-reach.ts,
#584). It has to be, because !connector is wrong in the other direction too — every supervision
tool has a connector and never leaves the platform.

changesAnything is t.mutates === true || mayWrite(t). The || mayWrite(t) is not redundant: it
falls back to the pre-#563 predicate for an older API that sends no mutates, and on a modern
response it keeps this from ever contradicting the checkbox set — a row that somehow arrived
mutates:false with a write gate on it must not let the read-only sentence render above a control
offering to let the agent act as you.

AC2 — mayWrite decided separately, and its argument answered rather than overwritten. Met.

It stays on scope + writeConsent. The reason is recorded in its docstring: it feeds exactly
one thing, the set of connectors that get a write-access checkbox. That is a question about the
gate, and scope/writeConsent are the gate's own inputs (writeConsentOf, server side).
mutates answers a different question and would put a checkbox under a tool the gate never
consults — a control that grants nothing, the mirror of the switch-that-does-nothing #351 removed.

The consistency this issue was reaching for is real and now lives where it belongs. fetch_url and
http_request are the same shape (the caller names the verb) and the sentence treats them
identically, because it reads mutates — which mutatesBuiltin derives from that same shape, so
they cannot drift. They differ in mayWrite only in whether a connector exists to be granted, which
is the honest difference between them.

writeConnectors's output is unchanged for every policy, pinned over all 256 combinations of eight
fixtures against an independent expression of the rule.

AC3 — the masked case is pinned, and it is labelled synthetic. Met.

counts a mutating tool the consent gate calls a read: a policy holding read_memory and
start_work (mutates:true, scope:"read", no connector) and no write_memory. It asserts
startWork.scope === "read" first — naming the field the old predicate read — then that the summary
does not claim read-only.

The test says in its body that no real instance can produce this policy and points at the server-side
guard that proves it, so nobody hunts for the live instance, exactly as this comment asked.

Watched fail (ADR 0002 G4): restoring the two old clauses turns 9 console tests red, this one
among them.

AC4 — the invariant is recorded as a measurement, not a comment, and it names the set. Met.

Both corrections from the comment above are taken. tool-reach-report.test.ts asserts, for every
capability shape toolNamesFor branches on (declared-allowlist, repo, coding, coding+drive:false,
FULL):

• all six connector-less platform writes are present — write_memory, delete_memory,
  create_task, update_task, configure_board, set_user_preference — each by name, so removing
  one fails by name rather than silently;
• each of them still resolves reach: "platform", which is what the argument actually rests on;
• fetch_url is present and resolves reach: "internet" — the reason the own-data sentence is
  now unreachable in production too, for the same structural reason the read-only one was.

Nothing depends on the invariant any longer; what it explains is why those two sentences do not
render, which the header states so the next reader does not re-derive it as a bug. The
allowed || disabled point is recorded in the console module's header for the same reason.

Verified live

Enumerated over all 34 instances on the deployed API with the real console module: 0 of 34 render
the read-only sentence (unchanged, and now correct by derivation rather than by accident), 0 of
34 render the false own-data claim (was 10), 34 of 34 render the true one. Every one of the
104 rows now carries both mutates and reach.

Gates

Full suite 8831/8831, pnpm typecheck, biome --error-on-warnings, all eight check-*.mjs,
docs:drift, console tsc --noEmit + vite build, e2e/console.spec.ts on chromium and webkit.
CI, Deploy API and Deploy Host green on 31194df.