[bug] An agent refuses work it IS allowed to do — the prompt says every write tool "needs consent" and never says the consent is granted

[serge-ivo]

Reported

The owner asked Heartfull (tmux) (cda75e28) to have an agent pull the latest code. It replied:

"…write access is currently blocked so I can't send commands directly. To enable this, please go
to the Settings tab and turn on write access for the terminal connector."

Write access was already granted. Live, on that instance:

terminal_run_command   allowed:true  reason:"ok"  writeConsent:"granted"
terminal_send_keys     allowed:true  reason:"ok"  writeConsent:"granted"
terminal_new_target    allowed:true  reason:"ok"  writeConsent:"granted"
terminal_kill_target   allowed:true  reason:"ok"  writeConsent:"granted"

It also never tried: the only execution recorded for that turn is terminal_list_targets. The agent
declined work it was permitted to do, invented a reason, and sent the owner to switch on a setting
that was already on.

Cause: the prompt states the gate and never states whether it is open

agent-think.ts:552 renders the tool list:

.map((t) => `- ${t.name}${t.scope === "write" ? " [write — needs the connector's consent]" : ""}: ${t.description}`)

That suffix is unconditional. Every write tool is labelled "needs the connector's consent"
whether or not the consent exists — and each tool's own description says it again
(connectors/terminal.ts:89,116,146: "WRITE: … requires terminal write consent").

So the model is told twice per tool that a gate exists and never once told the gate is satisfied.
Asked to run a command, the plainest reading of its own tool list is "I need a consent I do not
have" — so it refuses and helpfully explains how to grant it. The behaviour is not a
hallucination so much as the prompt's most natural interpretation.

The platform has the answer at that moment: writeConsent is resolved per tool and served to
/v1/instances/:id/tools (that is where the table above comes from). It is simply not put in front
of the model.

Why this one is expensive

• It converts a working agent into a broken one silently. Nothing errors; the owner is given a
  confident, plausible instruction that cannot help, and the natural next step — toggling the
  setting off and on again — changes nothing.
• It is worst on exactly the agents that matter: every runner-backed agent's useful tools are
  writes.
• Consent exists to make a real refusal meaningful. A refusal that fires when consent IS granted
  teaches the owner to distrust the gate.

Suggested fix

1. Render the resolved state, not the rule:
   [write — consent granted] / [write — consent NOT granted: ask the owner to enable the connector's write access in Settings]. Then a refusal is accurate and, when it is genuine, so is
   the remedy.
2. Say what to do when it is genuinely blocked, once, in the prompt — rather than leaving each
   agent to compose its own version of the instruction. The current message names the right tab by
   luck.
3. Consider dropping the per-description repetition (connectors/terminal.ts et al) once the
   list carries the resolved state: two statements of a rule and none of the fact is what produced
   this.
4. Cheap guard: a test that a prompt built for an instance with granted consent does not
   contain the string "needs the connector's consent" for a granted tool.

Same family as #395 and #398

The model asserted a platform state it had not checked, and the platform never offered it. #395 is
the same failure with tool results, #398 is why results are indistinguishable from claims. Here the
missing fact is a permission. In all three the platform knows and does not say.

Evidence: list_instance_tools(cda75e28) + instance_messages, 2026-08-08. Files:
workers/api/src/agent-think.ts:552, workers/api/src/lib/connectors/terminal.ts:89,116,146.

[serge-ivo]

Shipped in ba82fe9. Deployed.

The prompt now renders the verdict, not the rule. agent-think.ts asks writeConsentOf — the same function the /v1/instances/:id/tools listing and the runtime consent gate already use, so there is one source of truth for the answer rather than a second one that can disagree — and labels each write tool GRANTED, you may call this or NOT granted: … naming the connector. Reads get no label at all; the old suffix appeared on every write tool whether or not the consent existed, which is what made "I need a consent I do not have" the plainest reading of the tool list.

The two per-call gates are kept distinct rather than flattened into "blocked" — MCP's per-server consent (#262) and http_request's verb gate (#307) are different questions with different remedies, and collapsing them would have reproduced this bug one level down.

Consent rows are read per turn and fail-closed. A cache here is the bug: the whole defect is a stale belief about a permission.

Item 2's remedy sentence is stated once, in both states, so an agent no longer has to compose its own version and name the right tab by luck. Item 4's guard is in: a prompt built for an instance with granted consent must not contain the "needs the connector's consent" string.

Item 3 skipped deliberately — dropping the per-description repetition in lib/connectors/terminal.ts was outside this lane (that file was being edited by #404 in parallel). It is genuinely separable now: the resolved label outranks the description, so what remains is redundancy rather than contradiction. Worth a follow-up ticket.

Not verified live. The check on Heartfull (tmux) cda75e28: ask it to run something and confirm it now attempts the call instead of sending you to a setting that is already on.

[serge-ivo]

Verified delivered across two commits — ba82fe9 (items 1, 2, 4) and 067ba9b / #419 (item 3, which ba82fe9 deliberately deferred because connectors/terminal.ts was being edited by #404 in the same batch). All four are now in main and deployed.

1. The resolved state, not the rule. lib/connector-tool-prompt.ts → consentLabel renders [write — consent GRANTED, you may call this] / [write — consent NOT granted: this call will be refused until the owner enables write access for the <connector> connector], and a read gets no label at all — the old suffix appeared on every write tool whether or not the consent existed, which is what made "I need a consent I do not have" the plainest reading. Verdicts come from writeConsentOf in instance-tool-policy.ts, the same function /v1/instances/:id/tools and the runtime gate use, so the prompt cannot develop a second opinion about consent from the gate it describes. Read per turn and fail-closed: a cache here would be the bug, since the whole defect is a stale belief about a permission.
2. The remedy stated once, in both states, so an agent no longer composes its own version and names the right tab by luck.
3. The per-description repetition is gone — 067ba9b removed "requires … write consent" from 14 tool descriptions across terminal, tmux, browser, github, meta and google_sheets; what remains is the part only a description can say (WRITE: runs on the user's machine, WRITE: acts as the signed-in user). Confirmed by grep on today's main: no requires … write consent string survives in lib/connectors/.
4. The guard is in — a prompt built for an instance with granted consent must not contain the "needs the connector's consent" string (connector-tool-prompt.test.ts).

One thing ba82fe9's comment flagged and I have not done: the live check on Heartfull (tmux) cda75e28 — ask it to run something and confirm it attempts the call rather than sending you to a setting that is already on. I have no production session from here, so that specific behavioural confirmation is still outstanding. The prompt-level fact it depends on is verified in code and in tests.

Same family as #395 (closed) and #398 (closed); #406, the fourth, shipped in fb1ae10.