The tool list omits the one tool that reads the owner's mail: find_confirmation_link is granted by a checkbox 31px below a panel that says it is "not declared"

[serge-ivo]

Measured against production and main @ 8bf125c4 on 2026-08-21.

What the owner sees

Settings → Permissions & Connections renders, in one card, in this order:

1. Tools — captioned "Everything this agent is allowed to do." (ToolPermissions.tsx:120-122)
2. Agent write access — the connector consent checkboxes.
3. ☐ "Allow this agent to read my inbox for sign-in links & codes" (SettingsTab.tsx:588-598)

Measured in WebKit at 420px against proagentstore.online, on a Repo Coder instance: the Gmail checkbox's bounding box top is 31px below the write-access checkbox's bottom (4856.17 vs 4825.17). Same card, same heading, no separator.

Ticking (3) really does give the agent a tool that reads the owner's Gmail. Panel (1), which claims to list everything the agent is allowed to do, never mentions it — before or after.

The mechanism: two places compute "this agent's tools" and only one knows about the flag

The chat runtime applies the permission grant. workers/api/src/agent-think.ts:827-828:

const allowedToolNames = toolNamesFor(capabilities);
if (state.permissions?.email === true) allowedToolNames.add("find_confirmation_link");

…and again for what the model is shown, workers/api/src/agent-do-tools.ts:282:

// Permission-gated tools are only offered to the model when the user granted them.
if (opts?.emailEnabled) enabled.add("find_confirmation_link");

The listing does not. workers/api/src/lib/instance-tool-policy.ts:214-219:

const declared = toolNamesFor(capabilities);
...
const isDeclared = declared.has(t.name);
const reason: ToolPolicyReason = !isDeclared ? "not_declared" : ...

toolNamesFor (agent-do-tools.ts:226) takes capabilities and nothing else. find_confirmation_link is deliberately excluded from CREATOR_SELECTABLE_TOOLS — agent-do-tools.ts:266 says so and gives the reason — so it can never be declared, so this resolver can only ever return not_declared for it, whatever the owner has granted.

The console then drops the row entirely: listedTools keeps allowed || disabled (store/console/src/lib/toolPolicy.ts:~131), and a not_declared row is neither.

Measured on the one instance where the flag is actually on

Across all 43 instances of the operator account, exactly one has permissions.email === true: Job Application Assistant (51a3404e-9f78-4dbf-89b1-7a6976ce52c3). Live GET /v1/instances/51a3404e…/tools:

{"name":"find_confirmation_link","allowed":false,"disabled":false,"reason":"not_declared","reach":"internet"}

• rows the console lists: 39
• find_confirmation_link among them: no
• rows it reports as reaching outside the platform: fetch_url, submit_job_application, read_terminal, send_to_cli — the mailbox reader is not one of them

So on the single agent in this account that has been granted access to the owner's mail, the platform's authoritative answer to "what can this agent do" says that tool is not this agent's. The only thing on screen that says otherwise is a checkbox whose production label claims a narrow purpose ("sign-in links & codes").

This is the same defect the resolver was already fixed for once. instance-tool-policy.ts:189-193:

"eleven BASE names with no registry entry — write_memory, fetch_url, create_task and the rest — were invisible to an operator auditing what an agent may do, while the chat ran them."

Same shape, one tool later, on the mailbox.

Why the obvious fix is the wrong one

The first thing that suggests itself is to stop rendering the checkbox where Gmail is irrelevant. It is well supported on the surface: showsEmail = showsConnector(emailStatus) (SettingsTab.tsx:400) consults only the account, while its two neighbours use showsFileConnector(…, connectorPolicy, …) (:401-402) and additionally consult the per-instance verdict — the #352/#353 narrowing that Gmail never received. Measured: the checkbox renders on 43 of 43 instances, and GET /v1/instances/:id/connectors returns gmail: {allowed:false, reason:"no_tools"} on 43 of 43.

Do not do it. The comment at SettingsTab.tsx:576-583 is right, and it is right for a reason that outlives the connector work:

"…disabled rather than hidden while the account is disconnected, because agent-think.ts still offers find_confirmation_link on this flag alone: hiding the checkbox would remove the only control that turns off something still set."

Verified: agent-think.ts:828 adds the tool for any instance whose flag is on, irrespective of capabilities.tools. The connector policy's no_tools verdict is about the seven gmail_* connector tools (#711/#713/#716) and says nothing about this built-in. Gating the checkbox on it would hide the off-switch for a live capability on every instance that has it — a permission you cannot revoke, which is strictly worse than the confusion being fixed.

The checkbox is not in the wrong place. The listing above it is wrong.

What to do — cheapest first

1. Make the listing tell the truth (the fix). Give resolveToolPolicy the same input the chat runtime has:

export function resolveToolPolicy(
    capabilities: AgentCapabilities,
    disabledTools: readonly string[] = [],
    tools: ReadonlyArray<PolicyInput> = allToolPolicyInputs(),
    consentedConnectors: readonly string[] = [],
    grantedByPermission: readonly string[] = [],   // ← new
)

const declared = new Set([...toolNamesFor(capabilities), ...grantedByPermission]). The resolver stays pure; routes/tools.ts resolves permissions.email from the instance DO — lib/connectors/gmail.ts already has the proven fail-closed helper (emailPermitted, reads https://agent/state, treats every uncertainty as not permitted) — and passes ["find_confirmation_link"] when it is on.

Once the row is allowed:true, the existing UI does the rest for free: it appears in the Tools list with its own description and its own off-switch, reachesOutside counts it, and toolScopeSummary stops being able to assert a reach negative over it.

2. Give the not_declared case an honest reason. With the flag off, find_confirmation_link reads not_declared, which means "belongs to some other agent" and is false — it belongs to this agent as soon as one checkbox is ticked. Either add a reason value (needs_permission) or leave it out of the listing entirely; the current answer is the one thing it should not be.

3. Collapse the three call sites. toolNamesFor(capabilities, { emailEnabled }) would let agent-think.ts:828, agent-do-tools.ts:282 and the resolver derive one set from one rule. Three copies of "and also this tool if the flag is on" is why the third one was forgotten. Worth doing as part of (1); not worth blocking (1) on.

4. Separate the two controls visually. They are 31px apart under one heading and read as one control — an owner asked about "gmail / write access" directly above "read my inbox" reasonably concludes they are the same switch. A rule or a sub-heading between the connector consents and the per-agent permission is enough; there is no need to move either.

Relationship to work already in flight

• The label of the checkbox is being rewritten right now — there is an uncommitted change in the working tree replacing "read my inbox for sign-in links & codes" with "reach my Gmail" plus a sub-line pointing at the tool list. That copy is the right direction and this issue does not duplicate it. It does depend on it: the new copy says "Which of them it may actually use is the list above", and until (1) lands the list above does not contain the tool the flag grants, so the new sentence points at an empty answer.
• gmail.modify is declared but never requested: archive and mark-read can never work, and every Gmail account now reads "read-only — reconnect to allow sending" that reconnecting cannot clear #717 (gmail.modify declared but never requested) and [design] Gmail is granted all-or-nothing in practice: no read-only connect, no way to elevate later, and "decline it at Google's screen" is stated nowhere the user will see it #718 (all-or-nothing Gmail grant) own the OAuth grant layer. Not this.
• The write-consent panel describes a browser for every connector — 27 of 32 instances are told an agent will "click, type and navigate on your machine" about a cloud API #720 owns the write-consent panel's description. Not this.

Acceptance criteria

• With permissions.email === true, GET /v1/instances/:id/tools reports find_confirmation_link as allowed:true, reason:"ok", and the console lists it with its description and an off-switch.
• With the flag off, its reason is not not_declared.
• toolScopeSummary on an otherwise platform-only agent with the flag on no longer asserts "no tool that reaches outside the platform".
• The Gmail permission checkbox still renders on every instance where the flag can be set, including agents that declare no gmail_* tool, and still renders while the account is disconnected.
• A test asserts the containment the resolver's own header already names, extended to permission grants: everything agent-think.ts puts in allowedToolNames appears as allowed:true in resolveToolPolicy for the same inputs.

Regression risk

• Hiding the checkbox is the regression, and it is the fix a reader will reach for first. It would remove the only off-switch for find_confirmation_link on every instance holding the permission. Caught by the last acceptance criterion above; worth a comment at the change site, because the argument is not local to it.
• A DO state read now sits in the /tools path. It must fail closed and must not fail the request: an unreadable state means "not permitted" (as emailPermitted already does), not a 500 — ToolPermissions.tsx:41-53 records why a dropped read on this panel is the worst possible silent failure.
• allowed:true also un-gates the tool for POST /v1/instances/:id/tools/:name. Check whether the invoker gates on the same policy; if it does, this becomes a real reach change (the owner invoking their own permitted tool — defensible, but it should be a decision, not a side effect). find_confirmation_link carries invocableBy — confirm it stays ["chat"].

Open question for the owner

Should find_confirmation_link become an ordinary declarable tool now that Gmail is a first-class connector with seven declared tools? agent-do-tools.ts:266 argues it should not — "it is granted by what the agent IS" — and that argument was written when it was the only Gmail tool in existence. It is now the only one that bypasses capabilities.tools, which means a creator's declaration cannot describe an agent's full mailbox reach. I would keep it as-is for this ticket (the fix above is smaller and unblocks the copy already in flight) and treat the question as belonging with #718's grant-model work.

[serge-ivo]

Fixed in 8b5757bc, deployed (Deploy API Worker + Host Worker green).

The obvious fix was NOT taken

Recording this first because the issue is right that it is the change a reader reaches for. The Gmail checkbox was not hidden or gated on the connector verdict. Re-verified at HEAD: agent-think.ts adds find_confirmation_link for any instance whose permissions.email flag is on, irrespective of capabilities.tools, so narrowing the control the way Drive's is narrowed would have deleted the only off-switch for a capability that stays live. The argument is now recorded at both ends — at the checkbox (already there, SettingsTab.tsx:576-583) and at the resolver — because it is about the relationship between the two and a reader arriving at either end has to meet it.

What GET /v1/instances/:id/tools now returns for find_confirmation_link

state	verdict
permissions.email === true	allowed:true, disabled:false, reason:"ok", reach:"internet" — listed with its description and a working off-switch
flag off	allowed:false, reason:"needs_permission" — a new fourth ToolPolicyReason member. Never not_declared again (AC 2)
DO state unreadable	same as off, and the request still 200s — pinned by a route test with a 500-returning AGENT binding

resolveToolPolicy takes a fifth argument grantedByPermission — names, not a flag, so the resolver still knows nothing about Gmail — unioned into declared. That is the same shape of fix the eleven BASE names got at instance-tool-policy.ts:189-193, which the issue asked for rather than a second pattern. instanceToolPolicy resolves it at the single funnel all four routes/tools.ts call sites go through, using emailPermitted exported from connectors/gmail.ts rather than re-implemented, issued in a Promise.all alongside the existing consent query — one extra DO read per listing, fail-closed on every uncertainty.

The regression check you asked for — reach did NOT widen

POST /v1/instances/:id/tools/:name calls getRegistryTool(name) first; find_confirmation_link is a built-in, so the route 404s via builtinToolRouteRefusal before the policy is consulted. builtinToolPolicyInputs() hardcodes invocableBy: ["chat"] for every built-in, and it stays ["chat"]. MCP's call_instance_tool proxies that same route, so it is covered by the same gate. Both asserted by test, granted-state included. So allowed:true did not become "callable over REST/MCP" — it is a listing change only.

The containment test (the deliverable)

instance-tool-policy.test.ts — "everything the chat runtime would run for %s is allowed:true here, flag on and off", over five capability shapes × both flag states, re-deriving agent-think.ts's two lines rather than restating them. That is the test that goes red if someone "fixes" this the obvious wrong way.

Also: the PUT off-switch now refuses both absence verdicts through a new agentLacksTool(reason) predicate. Extracting it to tool-refusal.ts also kept routes/tools.ts under the file-size ratchet rather than raising the pin.

Acceptance

• flag on → allowed:true, reason:"ok", listed with description + off-switch
• flag off → reason is not not_declared
• toolScopeSummary no longer asserts "no tool that reaches outside the platform" on a platform-only agent with the flag on (reach:"internet" now counts)
• the checkbox still renders on every instance and while the account is disconnected — nothing feeding showsEmail was touched
• containment test extended to permission grants
• comment at the change site

Left undone, deliberately

• Item 4 (the 31px visual separation). Lives in store/console/src/tabs/SettingsTab.tsx, which had uncommitted work from another session in the tree throughout this work. I did not touch it — git diff --name-only returns zero matches for that file. This is the one acceptance item not delivered and it needs a follow-up or a hand-off to whoever holds that file.
• Item 3 (collapsing the three call sites into toolNamesFor(caps, {emailEnabled})). Not required for correctness, and the issue itself says not to block on it; agent-think.ts and agent-do-tools.ts are hot shared files. The containment test now covers the drift it would have prevented.
• The open question (should find_confirmation_link become an ordinary declarable tool) is untouched, as the issue recommends — it belongs with [design] Gmail is granted all-or-nothing in practice: no read-only connect, no way to elevate later, and "decline it at Google's screen" is stated nowhere the user will see it #718's grant-model work.

Not verified

I did not observe this live. These routes are instance-scoped and I hold no session token; verifying the Job Application Assistant row now renders needs an authenticated read of GET /v1/instances/51a3404e…/tools. Everything above is verified by test and by reading. Worth a 30-second check next time you have the console open: the tool should now appear in the Tools list on that one instance.

CI note: pnpm test:e2e is red on main and was red before this work (8bf125c4, 19027175, f8638ab9 and now 668f2e5d — 2 failed / 429 passed, identical every time). It is /console/preferences at 320px/1.3x, unrelated to this change, and filed separately.

[serge-ivo]

Reopening. The five acceptance criteria in the issue body are all met and shipped in 8b5757bc, but item 4 of "What to do" is not done — the visual separation of the connector-consent checkboxes from the per-agent Gmail permission, which are 31px apart under one heading.

That change lives in store/console/src/tabs/SettingsTab.tsx, which had uncommitted work from another session in the working tree for the whole of this work, so it was off limits to me. Closing this while naming it as undelivered in the same breath was wrong; it stays open until item 4 lands or is explicitly dropped.

Nothing else is outstanding — the listing fix, the needs_permission reason, the fail-closed DO read, the invocableBy non-regression and the containment test are all in and deployed.

[serge-ivo]

Still blocked on the same file, still open. Nothing delivered this round.

Item 4 — the ~31px separation between the connector write-consent checkboxes and the permissions.email checkbox — is unambiguously a store/console/src/tabs/SettingsTab.tsx edit, and I confirmed that rather than assuming it. Both controls are direct children of the same <Card> in that file: <ToolPermissions instanceId={instanceId} /> (which renders the write-consent checkboxes internally), then the two FileConnectorPanels, then the {showsEmail && (<label …>)} block. The separator belongs between the first and the last, in the parent.

The one alternative I considered — putting a trailing rule inside ToolPermissions.tsx instead — is wrong on its own terms: it would draw a rule even when showsEmail is false, and the separator's entire meaning is "what follows is a different kind of control", which only the parent knows. There is no way to deliver item 4 without editing SettingsTab.tsx.

Why I did not edit it

SettingsTab.tsx has carried another session's uncommitted work in the shared working tree for this entire run — verified at the start and again at the end, roughly 40 minutes apart. It is still dirty now; its last commit is 075ba7f6 (#366), well before this work.

That uncommitted diff is the copy rewrite this issue's body predicted: it replaces "read my inbox for sign-in links & codes" with "reach my Gmail" plus the sub-line ending "Which of them it may actually use is the list above". So the file is actively in flight, on this very control, in another session.

Editing it from a worktree would have been strictly worse than leaving it. My commit would carry the origin/main version of the file without that in-flight copy work, and whichever of us committed second would silently drop the other's change. That is a real risk of losing someone else's finished work to save a one-line layout edit.

The rest is unchanged and still done

The listing fix, the needs_permission reason, the fail-closed DO read, the invocableBy non-regression and the containment test all shipped in 8b5757bc and are still in place at HEAD — re-verified, not taken from the previous comment: instance-tool-policy.ts carries grantedByPermission at :252, unioned into declared at :254, and needs_permission at :264.

Item 3 (collapsing the three call sites into toolNamesFor(caps, {emailEnabled})) also stays undone, which I agree with: the issue itself says not to block on it, both remaining call sites are hot shared files, and the containment test already covers the drift it would prevent.

Live verification: attempted, and it failed — reporting that rather than papering over it

The previous comment left "the tool should now appear in the Tools list on that one instance" as an unverified 30-second check, so I dispatched a read-only investigator at production to close it. It could not run: no mcp__proagentstore__* tools were attached to that session at all, and the local mcp-needs-auth-cache.json records proagentstore as needing authentication since 2026-08-20. It correctly refused to substitute a code reading for a live read — a code reading would produce a confident answer about what production should return, which is exactly the claim this issue exists to test.

So GET /v1/instances/51a3404e…/tools is still unconfirmed against live. The 8b5757bc fix is verified by test and by reading only. Someone with a console session open should still do that 30-second check.

What is left on this issue

• Item 4 — a rule or sub-heading between the connector consents and the per-agent Gmail permission, in SettingsTab.tsx. Blocked purely on file ownership, not on any question of design. Whoever holds that file should take it, ideally in the same commit as the copy rewrite already sitting there — the two are the same paragraph of UI.
• Live confirmation that find_confirmation_link now lists on the Job Application Assistant instance.

Everything else on this issue is delivered.