Every Gmail call on a two-mailbox account refuses, and all three surfaces point at a Settings picker that was never built (#715's unfiled follow-up)

[serge-ivo]

What the owner sees

Connect a second Gmail and every Gmail tool on every agent stops working, on all seven tools of the #711/#713/#716 wave plus find_confirmation_link. Three separate surfaces tell the owner to fix it on the instance Settings tab. There is no such control on the Settings tab, anywhere in the console, or over MCP. The only way out is a hand-written curl.

Measured live, 2026-08-23, operator account, deployed API:

GET /v1/instances/51a3404e-9f78-4dbf-89b1-7a6976ce52c3/connector-accounts
  → { "connector": "gmail",
      "pinned": null,
      "resolves": null,
      "blocked": { "reason": "ambiguous",
        "message": "You have 2 Gmail accounts connected and this agent is not set to use
                    one of them: sivochkin@gmail.com, serge.pro.job@gmail.com. Choose which
                    account this agent should use in its Settings — nothing is sent or read
                    until you do." } }

That instance is the Job Application Assistant — the only one of the account's 43 with permissions.email: true (verified: GET /v1/instances/51a3404e…/state → {"permissions":{"email":true}}). Meanwhile GET /v1/email/status returns connected: true, so the console shows Gmail connected and the permission ticked while every call refuses.

The mechanism

Two individually-correct decisions.

1. The refusal is deliberate and right. lib/connector-accounts.ts:110-119:

	if (accounts.length === 1) return { ok: true, account: accounts[0] };

	return {
		ok: false,
		reason: "ambiguous",
		message:
			`You have ${accounts.length} ${displayName} accounts connected and this agent is not set to use one of them: ` +
			`${accounts.map(describe).join(", ")}. ` +
			`Choose which account this agent should use in its Settings — nothing is sent or read until you do.`,
	};

The module header argues for this at length and I agree with it: reading the wrong mailbox "silently answers from the wrong life". Every Gmail tool routes through it — connectors/client.ts:106 chooseAccount for the seven registry tools, and lib/storage-tools.ts:574-584 for find_confirmation_link, which 32f0f414 moved onto the same resolver three days ago (correctly — it used to .first() an arbitrary row).

2. The control the refusal names was never built. #715 closed on 2026-08-20 with its own item 4 unbuilt, and its closing comment says so:

Not done here: the per-agent picker UI on the instance Settings tab. The routes are live and documented (GET/PUT /v1/instances/:id/connector-accounts); until it lands the choice is set over the API. Filing that separately.

It was not filed. Issues #716–#733 are all accounted for and none is this.

Verified absence. grep -rn "connector-accounts\|connectorAccounts" over the whole repo returns hits in workers/api/src/{routes/tools.ts,lib/connector-accounts.ts,lib/connectors/*,routes/email.ts} and store/openapi.yaml:6480 — and zero in store/console/src, agents/coder/web/src or workers/mcp/src. store/console/src/tabs/SettingsTab.tsx has no account control; its only sentence on the subject points elsewhere (:549): "or disconnecting an account is account-wide and lives in Preferences → Connections."

Three surfaces make the same false promise

1. The runtime refusal above — "Choose which account this agent should use in its Settings".
2. lib/connector-accounts.ts:104-106, the stale-pin refusal — "choose a different account for this agent in its Settings".
3. store/console/src/components/AccountConnections.tsx:226-230, which is rendering on the live Preferences page right now because this account has two Gmails:

	<p className="text-2xs text-muted-soft mt-1">
		Each agent must be told which of these to use, on its own Settings tab. Until it is,
		that agent will not read or send anything through {entry.label}.
	</p>

The second half of that sentence is true and measured. The first half names a tab that has nothing on it.

What to do — cheapest first

a. The one-screen fix. Render an account picker in the existing Permissions & Connections card on SettingsTab.tsx, gated on needsPerAgentChoice(entry). That predicate already exists and is already exported — store/console/src/lib/accountConnections.ts:77 — and is currently called only from AccountConnections.tsx, i.e. from the surface that tells you to go elsewhere. accountRows(entry) supplies the labels. The wiring is GET /v1/instances/:id/connector-accounts on mount and PUT { connector, accountId } on change; both routes are live, owner-scoped, and refuse an account the owner does not hold (routes/tools.ts:102-126).

Show the current blocked.message inline when resolves === null, so the panel states the consequence rather than presenting an optional-looking dropdown.

b. An MCP path — get_instance_connector_account / set_instance_connector_account. Not required for this issue, but the console is currently the only planned door and an owner debugging over MCP has none. File separately if wanted.

c. Do not relax the refusal to "pick the newest" or "pick the one used last". That is the decision #715 made on purpose and this issue is not asking to reopen it.

Rejected

• Auto-pin the single account that can do the job (e.g. the only one with gmail.send). It resolves today's account by accident and breaks the moment both mailboxes have the scope, which is the shape of bug Multiple accounts per connector — one Gmail per user is a primary key, and GitHub already does it right #715 exists to prevent.
• Hide the Gmail permission checkbox while ambiguous. 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" #721 recorded, at lib/instance-tool-policy.ts and at the checkbox, why hiding that control is a regression: agent-think.ts offers find_confirmation_link on the flag alone, so removing the checkbox deletes the only off-switch for a live capability. Same argument applies here.

Acceptance criteria

1. With ≥2 accounts on a connector, the instance Settings tab shows which account this agent uses and lets the owner change it, without leaving the console.
2. With pinned: null and ≥2 accounts, the panel renders the blocked.message the API already computes — the owner learns the agent is inert before a tool call tells them.
3. With exactly one account connected, nothing new renders (matches needsPerAgentChoice's existing threshold, so nobody who never adds a second sees a change).
4. Setting the pin makes GET …/connector-accounts report resolves: "<accountId>", blocked: null, and a Gmail tool call on that instance stops refusing.
5. Clearing the pin returns the instance to blocked.reason: "ambiguous" rather than silently reverting to a default.
6. AccountConnections.tsx:226-230's sentence is true — a test that the target control exists, or the sentence changes with it.

Regression risk

The picker writes agent_instances.config.connectorAccounts through patchInstanceConfig, which is patch-semantics, so it cannot clobber sibling config. The risk worth guarding is the one Preferences.tsx warns about and #355 was filed for: this control must choose among the owner's existing credentials and must never connect or disconnect one. PUT /connector-accounts already refuses an account the owner does not hold; the console test to add is that the panel renders no connect/disconnect affordance.

Verified vs inferred

• Verified: the live blocked payload, permissions.email: true on 51a3404e, email/status.connected: true, the two Gmail rows, the three quoted code sites, the repo-wide absence of any console/MCP reference to the routes, and that Multiple accounts per connector — one Gmail per user is a primary key, and GitHub already does it right #715's promised follow-up was never filed.
• Inferred, not observed: that a gmail_search call on a gmail-declaring instance refuses end to end. I did not run one — no instance in the account subscribes to Inbox Chat or Email Assistant, and driving the owner's agents to prove it is out of bounds. The resolver is the same one /connector-accounts reports through, and connectors/client.ts:100 throws HttpError(400, resolved.message) on !resolved.ok, so the path is read but not exercised.

[serge-ivo]

Shipped in c6d8c588, deployed, and live.

What was built

The picker, in the existing Permissions & Connections card on the instance Settings tab, directly under the tool allow-list — the two answer one question in sequence: what this agent may do, and whose mailbox it does it to.

As the issue directed, it reuses what already existed rather than adding a parallel copy. needsPerAgentChoice and accountRows were widened from ConnectorEntry to a HasAccounts subset, so one predicate now serves both the account page and the instance tab. A second copy is how the two surfaces would come to disagree about when a choice is owed — which is this bug.

blocked.message renders verbatim when resolves === null. Not paraphrased: it is the same string the tool refusal quotes, and three hand-written variants of that sentence already existed, one of them false.

Acceptance criteria, each with the guard that holds it:

1. Choice made in the console, pin reaches the server — e2e, asserts the recorded PUT body.
2. blocked.message rendered before a tool call reports it — unit + e2e on the live-measured string.
3. Nothing renders below two accounts — unit + e2e.
4. Setting the pin → resolves, blocked: null — e2e, against a fixture that mutates on PUT, so the panel cannot pass while showing a choice the server never took.
5. Clearing returns to ambiguous — e2e; the option reads "Not chosen — every call refuses", never "Automatic".
6. AccountConnections.tsx:226-230's sentence is now true — pinned by a test that fails if the sentence stays and the control goes, or vice versa.

The rejections, both honoured and both pinned

• No auto-pin. Nothing infers "the account that can do the job".
• The Gmail permission checkbox is untouched. 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" #721's reason stands: agent-think.ts offers find_confirmation_link on that flag alone.
• It chooses among credentials and can never establish one ([design] Account-level connections are rendered inside one agent's Settings — disconnecting Gmail there disconnects it everywhere #355). Two guards: a source test that the component reaches for no connect/disconnect endpoint — comments masked, or the docstring explaining [design] Account-level connections are rendered inside one agent's Settings — disconnecting Gmail there disconnects it everywhere #355 would satisfy it — and an e2e assertion that the rendered panel contains no button and no link.

Both new source guards were mutation-checked (ADR 0002 G4): planting a Disconnect button and unmounting the panel each turn them red.

Two things carried along, forced rather than chosen

• scripts/check-mcp-parity.mjs gains a KNOWN_GAPS entry. The console now calls a route MCP cannot reach, so the gate fails without one. Item (b) — get_instance_connector_account/set_… — is still not filed; the ratchet entry records the gap and names the reason.
• The shared e2e fixture now answers /connector-accounts. Unmocked it hit the 500 fallback, so the panel — correctly, per [bug] Stop swallowing runtime errors across voice, coder, and worker paths #291 — rendered a load failure inside the Permissions card on every Settings test in the file.

Verified

10,313 unit tests, 467 Playwright tests across chromium + webkit, the full ci.yml gate list, CI green on c6d8c588, Host Worker deploy succeeded. The panel is measured in WebKit at 320px and 390px using the two real addresses from the live reading rather than a@x.test — a hollow fixture is how the Profile page passed this guard while overflowing in production (#235).

Live in the deployed console bundle: agent-account-choice, connector-accounts, Which account this agent uses, Not chosen all present.

NOT verified — stated plainly

I did not confirm the end-to-end unblock on 51a3404e. Setting the pin needs the owner's session, and driving the owner's agents is out of bounds. So what remains unobserved is the last link: open Settings on the Job Application Assistant, choose a mailbox, and confirm GET …/connector-accounts reports resolves: "<accountId>", blocked: null, and that a Gmail tool stops refusing. Everything up to that point is verified; that step is not.

Leaving open until that is confirmed on the live instance.

[serge-ivo]

Audit verdict: PARTIAL. The picker is built and live in the deployed console. The gap the last comment named is confirmed to be the only one left — and it is still open.

Verified live, 2026-08-23

GET /v1/instances/51a3404e-9f78-4dbf-89b1-7a6976ce52c3/connector-accounts (Job Application Assistant, owner's session):

{ "connector": "gmail", "label": "Gmail",
  "accounts": [
    { "accountId": "sivochkin@gmail.com",     "connectedAt": "2026-08-20 20:39:54" },
    { "accountId": "serge.pro.job@gmail.com", "connectedAt": "2026-07-03 07:48:37" }
  ],
  "pinned": null,
  "resolves": null,
  "blocked": { "reason": "ambiguous", "message": "You have 2 Gmail accounts connected and this agent is not set to use one of them: … Choose which account this agent should use in its Settings — nothing is sent or read until you do." } }

pinned: null, resolves: null, still ambiguous. So the pin has not been set and the end-to-end unblock has still not been observed. That is exactly and only what c6d8c588 said it was leaving open.

The control itself is real and deployed — I checked the served bundle, not the source

store/console/src/components/AgentAccountChoice.tsx exists (:63 GETs /v1/instances/{id}/connector-accounts, :77 PUTs it, :107 data-testid="agent-account-choice", :109 "Which account this agent uses"). More usefully, all four strings are present in the live console served from https://proagentstore.online/console/:

agent-account-choice            1
connector-accounts              1
Which account this agent uses   1
Not chosen                      1

So a browser loading the console today has the picker. The only thing between the current state and AC4/AC5 is somebody choosing a mailbox.

The step that cannot be automated

This needs the owner's own browser session; a subagent holding a read-only session token can read the state (above) but must not write the pin. When you next have the console open:

Go to Job Application Assistant → Settings → Permissions & Connections. Under the tool allow-list there is now a "Which account this agent uses" row showing "Not chosen — every call refuses" and the blocked.message above it verbatim. Pick one of the two Gmail addresses.

What it looks like when it worked: the panel stops showing the blocked sentence, and GET …/connector-accounts for that instance reports resolves: "<the address you picked>" with blocked: null. I can re-read that endpoint and confirm it, so tell me when it is done rather than taking it as finished.

The remaining half of AC4 — "a Gmail tool call on that instance stops refusing" — is find_confirmation_link on the apply agent (that instance is the account's only one with permissions.email: true). Nobody should drive it just to prove the point; the resolves/blocked: null reading is the checkable half and the tool path is the same resolver.

Item (b) is still not filed, and the ratchet says so

scripts/check-mcp-parity.mjs:231-235 carries a KNOWN_GAPS entry for [A-Z]+ /v1/instances/{}/connector-accounts whose why records the deferral in full — a caller debugging over MCP still meets the dead end the console owner did: list_instance_tools reports a Gmail tool as allowed while every call refuses with ambiguous, and nothing over MCP can read that state or resolve it. get_instance_connector_account / set_instance_connector_account want their own issue.

VERIFIED vs INFERRED

• Verified: the live /connector-accounts payload; the four strings in the deployed console bundle; the component's two API calls; the parity ratchet entry.
• Inferred: nothing. I did not render the Settings tab in a browser — the served bundle carrying the testid and the copy is the evidence, and the e2e suite covers the render in WebKit at 320px and 390px.