[bug] The tmux Operator promises to fetch GitHub issues it has no tool to reach — the CONNECTED TOOLS list is never stated to be exhaustive

[serge-ivo]

The owner asked for GitHub issues four times, and got three turns of "tell me the repo and I'll fetch them"

Live conversation on Heartfull (tmux) (cda75e28-cace-4958-ac3e-6a7528e6b719, agent tmux-operator),
2026-08-10 22:46–22:50 UTC. The owner's machine was off, so the runner was down. Verbatim, from
agent_trace:

22:47:16 owner — "Can you check tickets for now? If you can't connect to the machine, at least you should be able to get the tickets and understand if it was closed or not, or still in progress."
22:47:27 agent — "The machine is still offline, so I can't check the code either. Please run pags up…"

22:48:10 owner — "Can't you use agent's tools on his behalf to get to the issues, proper issues in GitHub, on his behalf? Can't you use agent's tools at all?"
22:48:16 agent — "The runner on your machine isn't connected, so I can't reach tmux or GitHub through it right now. Please start it by running pags up…"

22:49:04 owner — "I'm not talking about the terminal, I'm talking about the interface. In fact, you just go into the GitHub interface and check what's open, what's not, without terminal, without tmux."
22:49:10 agent — "I don't have the GitHub repo URL stored in memory, so I can't look it up directly. Can you tell me the GitHub organisation or repo name so I can pull up the issues right now?"

The last sentence is the defect. The agent has no tool that can pull up an issue, with or without the
repo name. The owner supplied the repo anyway (next turn), and the agent asked for it a second time.

The owner's read of the session afterwards: "the agent itself could not file it." That is correct,
and it is also correct that nothing in the session ever told him so.

Verified

GET /v1/instances/cda75e28…/tools (MCP list_instance_tools, allowed_only:true) — the complete
connector-tool set for this instance:

tmux_list_sessions, tmux_capture_pane, tmux_run_command,
tmux_send_keys, tmux_send_message, tmux_new_session, tmux_kill_session

No github_* tool at any scope. The seed that fixes the list is
workers/api/migrations/0117_tmux_operator_send_message_tool.sql:37 (WHERE slug = 'tmux-operator'),
and capabilities.tools is an authoritative allowlist (workers/api/src/agent-do-tools.ts:187-190,
per #444), so nothing else can reach one.

For contrast, on the same account: coder-repo declares github_list_issues, github_read_issue, github_create_issue, github_list_pulls, github_read_pull, github_workflow_runs, and coder-lead
— surfaces: [], runtime: null, no repo, no terminal — declares github_list_issues, github_read_issue, github_list_pulls, github_read_pull. So there is no existing rule that GitHub
reads belong only to repo-surface agents; a purely conversational agent already has them.

Mechanism — two correct decisions, and one thing nobody says

1. The Operator's only route to GitHub is the machine that was off. tmux_run_command (scope: "write", arbitrary shell on the owner's box — workers/api/src/lib/connectors/tmux.ts) could run
gh issue list. That is the whole of its GitHub access, and it is unavailable in exactly the
situation the owner was in. Nothing in the cloud can answer a GitHub question for this agent.

2. Nothing tells the model its tool list is exhaustive. connectorToolsPrompt
(workers/api/src/lib/connector-tool-prompt.ts:131-149) emits:

"CONNECTED TOOLS — external actions you can take DIRECTLY by calling the tool (never tell the user to do it themselves, and never route it through a terminal/CLI)"

followed by CONSENT_RULE (:174-182), which is entirely about tools the agent has:

"Trust these labels — they are this agent's CURRENT, resolved permissions… Never decline a granted tool on permission grounds…"

There is no sentence anywhere in the built prompt saying the list is the complete set of external
systems reachable. selfDescriptionPrompt
(workers/api/src/lib/agent-self-description.ts:271-312) states two things for a tmux Operator —
single-repo ownership (not applicable) and "Your console has exactly these tabs: … NEVER refer the
user to any other tab". The tab list is closed by an explicit "NEVER"; the tool list is not
closed at all. Asked three times, with an owner insisting the capability exists, the plainest
reading available to the model is "I must be missing a parameter", and it asked for one.

This is the same shape as #399's finding, pointed the other way. #399: the platform knew consent was
granted and did not say, so the model refused work it could do. Here: the platform knows the tool
does not exist and does not say, so the model promised work it cannot do. The file header of
connector-tool-prompt.ts:1-36 already states the rule this violates — "State the fact, not the
rule".

Not this

• Not [arch] A registry tool that no agent declares is silently unreachable — three times in four days, and six more are live right now #444 (closed) — that guard catches a registry tool no agent declares. github_list_issues
  is declared by four agents; a specific agent lacking it is invisible to it, by design.
• Not [bug] The model writes its own tool RESULTS and the platform believes them — invented GitHub issues and file contents reported as fetched, raw markup left in the message #395/[bug] Tool results are fed back as the assistant's own prose and the tool_use turn is dropped — the format the model then imitated in #395 #398/[bug] A caught fabrication is only caught once — the invented turns stay in history and the model re-reads them as fact #406 — the agent did not invent a tool result; invented-results.ts correctly
  saw nothing to strip. It made a promise about a future call, which no existing guard covers.
• Not a runner outage. The runner being down is what exposed it; the agent has no cloud GitHub path
  when the runner is up, either.

What to do — cheapest first

Step 1 (one sentence, benefits every agent). Close the tool list in connectorToolsPrompt, the
way the tab list is already closed. Suggested wording, to sit next to CONSENT_RULE:

"This list is complete. If an external system is not represented above, you have no way to reach
it — say so plainly and name what you do have. Never ask for a detail (a repo, an org, a URL)
that would only be usable by a tool you have not been given."

Cheap, derived from the resolved tool set, and it fixes the wasted-turn class for every agent, not
just this one. Pair it with a behavioural eval in the shape #483 established: an Operator asked "what
GitHub issues are open?" must answer that it cannot reach GitHub, and must not ask for a repo name.

Step 2 (the capability decision). Declare read-only GitHub on the tmux-operator seed —
github_list_issues, github_read_issue, github_list_pulls, github_read_pull,
github_workflow_runs — in a new migration following the 0099/0117 pattern, and extend
workers/api/src/lib/tmux-operator-seed.test.ts (which already parses the migration and resolves it
through the real registry, so a typo cannot ship a tool-less agent).

The tools take the repo as an explicit owner/name argument
(workers/api/src/lib/connectors/github.ts:88-96, resolveRepo at :38), so this needs no repo
configuration to be useful — though it composes with the sibling issue below, which is why the agent
had to ask for the repo at all.

Why I would take step 2, not just step 1. The Operator exists to decide what to tell a CLI next,
and this owner's standing instruction to it is "we only work through GitHub issues. Everything
should be documented." (2026-08-10 08:09:30). Deciding that from a terminal pane, on a machine that
must be awake, is the capability delta the owner ran into. This instance is also explicitly one half
of a cost comparison against the coder-repo "Heartfull" instance (its Special Instructions:
"Same repository, same objectives, different driver") — and the Repo Coder has these tools. Without
them the experiment measures a capability difference and reports it as a driver difference.

Explicitly NOT github_create_issue. #447 (closed) documents that tmux-operator is the one
published Operator with no capability ceiling — CONNECTOR_CONSTRAINTS has no tmux key, so
tmux_run_command's arbitrary write shell is already ungoverned. Adding a second unbounded write
path before that is resolved would compound it. Read-only tools raise no new write-consent surface at
all.

Alternatives considered and rejected

• "Tell the user to run gh issue list in the pane." Rejected: requires the runner, which is the
  thing that was down; and it spends a write-scope arbitrary-shell tool on a read.
• Give the Operator the http connector instead and let it call the GitHub API. Rejected: http
  needs a vault key, which means the owner minting and storing a PAT for something the GitHub App
  already authorises repo-scoped (auth: "app", connectors/github.ts:1-12).
• A generic "here is what you cannot do" prompt block. Rejected: the complement of a tool set is
  not enumerable. Closing the list is the only tractable form of the same statement.
• Fix it in the seed personality only. Rejected: the two live instances of this agent do not
  receive seed personality edits — see the fourth issue in this batch.

Open question for the owner

Is an Operator meant to be strictly hands-on-the-terminal (in which case ship step 1 alone and the
honest answer becomes "I can only reach GitHub through your machine, and it is off"), or is it a
driver that reasons about work and therefore needs to read the tracker from the cloud? I would ship
both steps: step 1 is correct regardless, and step 2 is what makes the answer to the owner's actual
question "yes" rather than a better-phrased "no".

Acceptance criteria

• With no runner connected, asking a tmux-operator instance "what GitHub issues are open?" produces
  either the issues (step 2) or a plain statement that it cannot reach GitHub — never a request for a
  repo name it cannot use.
• tmux-operator-seed.test.ts asserts the new tool list resolves through toolNamesFor and contains
  no write-scope GitHub tool.
• A behavioural eval covers the ask-for-an-unusable-parameter failure.

Regression risk

• Closing the tool list could make an agent refuse something it CAN do via a base tool (fetch_url,
  start_work) that is not in the CONNECTED TOOLS block. The wording must scope to external
  systems, and the eval must include an agent that legitimately answers via fetch_url.
• Adding tools to a seed changes the resolved set for existing instances (tools resolve from the
  agents row, unlike personality) — verify against lintAgentClaims and the seed test, both of
  which already run in CI.

Evidence trail

Verified: the tool list (live MCP), the seed migration, the prompt builder lines quoted above, the
three chat turns (agent_trace, trace ids de92d7d3…, fffbf1d2…, 4c9d6e99…).
Inferred, and labelled as such: why the model asked for the repo name. I did not dump the assembled
system prompt for that turn — there is no endpoint that returns it — so the claim that the absence of
an exhaustiveness statement caused the ask is reasoning from the prompt source, not a measurement.
The absence itself is verified: grep -n "exhaustive\|complete list\|not represented" returns nothing
in connector-tool-prompt.ts or agent-self-description.ts.

[serge-ivo]

Step 1 shipped in 4031cbe (CI green, API Worker deployed).

What changed. TOOL_LIST_CLOSED in workers/api/src/lib/connector-tool-prompt.ts, appended to
every CONNECTED TOOLS block after CONSENT_RULE. It closes the tool list the way
selfDescriptionPrompt already closes the tab list, and forbids the two specific moves from the
transcript: asking for a detail only an absent tool could use, and offering a lookup it cannot make.

One correction to the proposed wording, and it matters. The issue suggested "If an external
system is not represented above, you have no way to reach it." That is false. fetch_url is in
BASE (agent-do-tools.ts:22) and BASE is seeded even under a declared capabilities.tools
allowlist (:191-193), so the Operator — like every agent — can fetch a public GitHub URL. Shipping
that sentence would have put a new false absolute on the prompt, which is the class of defect this
ticket is about. The shipped claim is the narrower true one: nothing outside the list has a
dedicated tool. The operative clause is the last one, and it is what actually fixes the observed
turn:

If you mean to try a general-purpose tool you DO hold, call it in the SAME reply and report what it
returned — never promise a lookup you have not made.

That is the part no existing guard covers. #395/#398/#406 and invented-results.ts all police an
invented result; here there was no result to strip, only a promise about a future call.

It also says explicitly not to send the owner to Settings, because it sits beside a rule that ends
by pointing at Settings → Connections. toolNamesFor resolves the set from the agent's definition
and a subscriber can disable a tool but never add one, so "ask your owner to connect GitHub in
Settings" would be the same dead errand by a different route.

Verified

• 25 tests in connector-tool-prompt.test.ts, including a negative guard that the "no way to reach
  it" absolute is not present.
• Acceptance driven from the real seed, not a fixture: migration 0117's tool names → the real
  registry → the real prompt builder (tmux-operator-seed.test.ts). It asserts the Operator has no
  github_* tool to list, so the guard cannot quietly become vacuous if step 2 lands.
• Full bar green (typecheck, 7,397 tests, biome, all six scripts, docs:drift). Deploy succeeded;
  api.proagentstore.online/health 200 after.

Not verified. The system prompt is not observable through any API, so I could not confirm the
sentence reaching a live turn. The 30-second check is to ask the Operator "what GitHub issues are
open?" — it should say it cannot reach GitHub and name what it does have, and must not ask for a
repo name.

Left open deliberately. Step 2 (declaring read-only github_* on the tmux-operator seed) is
your call and is not done. github_create_issue stays off the table per #447. Leaving this issue
open so that decision has a home; close it if step 1 was the whole ask.

[serge-ivo]

Decision brief — should the Operator get read-only github_*?

This is one decision, not two. #494 step 3 ("a GitHub tool for the deployment question") is the
same grant on the same connector at the same scope; the only difference is which tool names go in
the array. Decide it here; #494 carries a pointer and the deployment-specific delta.

Step 1 verified as shipped and on origin/main: TOOL_LIST_CLOSED
(workers/api/src/lib/connector-tool-prompt.ts:131-139) is appended after CONSENT_RULE in
connectorToolsPrompt (:197). The instance still has no github_* tool at any scope —
GET /v1/instances/cda75e28…/tools today returns the seven tmux_* plus the base set, nothing
else — so nothing about the capability has changed while the honesty has.

---

What the grant would cost, measured

	measured	how
Prompt, per turn	+671 chars ≈ +168 tokens	real registry + real connectorToolsPrompt, 7 tmux tools vs 7 + the 5 github reads: 4,675 → 5,346 chars
One github_list_issues result	6,146 chars ≈ 1,540 tokens ≈ $0.0046	the real toSummary shape (lib/github-issues.ts:83-93) over the live open issues of HeartFull-online/platform (17 open, PRs excluded); sonnet input $3/M (lib/ai-pricing.ts:23)
Operator's actual 30-day spend	$2.61 over 151 calls (373,372 in / 14,050 out)	/v1/usage byAgent bucket 2dff5c62…
Repo Coder's, same window	$2,649.25 over 997 calls, of which engine = $2,634.48 = 97.7% of the whole account	same call, byAgent + byKind

One correction to the figure quoted on #433. The $0.0027 / 54 calls row keyed cda75e28… is
not the Operator's chat spend — it is the platform-paid summariser and embedding sliver.
getStorageEngine meters those with agentId = the DO's own id, i.e. the instance uuid
(agent-do.ts:152-160), while chat records { kind: "chat", instanceId: state.agentId } with no
agent_id (agent-think.ts:745), and /v1/usage resolves that through
COALESCE(u.agent_id, i.agent_id) (routes/usage.ts:41) onto the template. So the Operator's
BYOK chat is the $2.61 / 151 calls bucket, shared with the other tmux-operator instance
(1a8486b5…) because that endpoint groups by agent, not instance — the per-instance split exists in
ai_usage.instance_id but is not aggregated. The direction of #433's conclusion is unchanged
(~1,000×, and 97.7% of the account is engine spend the tmux path cannot record at all); the tmux
side is 1,000× larger than the number in that comment.

Against $2.61/month, a few issue reads a day are cents. Against $2,649 they are invisible.

---

Option A — grant read-only GitHub (5 tools), no binding

github_list_issues, github_read_issue, github_list_pulls, github_read_pull,
github_workflow_runs, in a migration on the 0117 pattern (WHERE slug = 'tmux-operator' reaches
the live row — 2dff5c62… is the only agent with that slug in GET /v1/agents).

• No new consent surface. Read scope resolves writeConsent: "n/a"; the write-consent gate
  ([connectors] Connector consent + write-scope safety + admin visibility #90) is untouched. github_create_issue stays off, per [design] tmux is the one Operator connector with no capability ceiling — CONNECTOR_CONSTRAINTS has a single key, and #403 moved the published agent off it #447 — agreed, and nothing below changes
  that.
• Blast radius, verified. CONNECTOR_CONSTRAINTS has no github key — surface-options.ts:213-250,
  and surface-options.test.ts:381 asserts the keys are exactly ["terminal","tmux"]. The tools take
  repo as a free argument and mint a token per owner (connectors/github.ts:38 → github-app.ts:404),
  so the grant is "read any repo in any installation this account has": 16 installations, 10 named
  orgs (GET /v1/github/installations). The only bound on which repo gets read is the prompt.
• Published-agent reach. The row is the published tmux-operator, so every subscriber's
  instances gain it against their own installations. I could not establish how many subscribers
  exist outside this account; SELECT COUNT(*) FROM agent_instances WHERE agent_id='2dff5c62-59f0-4d2d-b0a6-b1db5c879c46' answers it in one query.
• Cost to ship: one migration + flipping tmux-operator-seed.test.ts:133-139, which currently
  asserts the operator has no github_* tool precisely so this decision cannot land silently.

Option B — step 1 only: the honest "no" stands

Free, already shipped. The Operator answers "I can only reach GitHub through your machine, and it is
off", which is now true and stated. Costs: the capability the two sibling agents already have
(FIS coder / coder-repo declares six github_* including create; Coder Lead / coder-lead
— surfaces: [], no repo, no terminal — declares four), and it leaves the A/B measuring a
capability difference while reporting a driver difference.

Option C — grant, and bind it to the configured repo

The end state that removes the blast-radius objection: a github entry in CONNECTOR_CONSTRAINTS
with a binding field on arg: "repo", exactly the shape 4fda69d just added for tmux
(surface-options.ts:243-249) — the machinery already resolves agent ceiling narrowed by instance
request (agent-capabilities.ts:590-612), so a per-instance bound repo is expressible today.

It has a design fork you would have to settle, and it is the reason I do not recommend it as the
first move: the binding is read from config.surfaceOptions.github.boundRepo, while #488's
Deployment card writes config.githubRepo. Copying the value into a second field re-creates #494's
exact defect one field over; teaching the lookup to source the existing field is the better answer
and is a change to shared machinery. Plus a PUT /v1/instances/{id}/<bindRoute> mount
(surface-options.ts:170-177, asserted against the table in routes/instances-terminal.ts:46).

---

Recommendation

Take Option A now, and put Option C on the backlog rather than in front of it.

1. The A/B is invalid today and Option A is what makes it valid. coder-lead already proves the
   platform has no rule that GitHub reads belong to repo-surface agents.
2. The measured cost is ~168 tokens/turn plus ~1,540 tokens per issue read, against an agent whose
   whole month is $2.61 and a comparison arm at $2,649.
3. Read scope adds no consent surface and no write path, so the [design] tmux is the one Operator connector with no capability ceiling — CONNECTOR_CONSTRAINTS has a single key, and #403 moved the published agent off it #447 ceiling problem is not
   compounded — that ticket is about tmux_run_command's ungoverned write shell, and this changes
   nothing about it.
4. The repo is no longer missing: ## Deployment (shipped this morning, 9390ab2) states the
   configured slug authoritatively, so the tools have something correct to be called with without
   asking the subscriber. That is a soft binding — prompt, not enforcement — and I am
   recommending you accept prompt-level scoping for now, on an account where all 16 installations
   are your own.

Re-baseline the cost comparison when you grant. Granting mid-experiment moves the tmux arm's
recorded cost; note the date and compare forward, or the A/B trades one contamination for another.

What would change my mind

• If any instance of the published tmux-operator belongs to someone whose installations you do not
  control (the count query above): then Option C first, because "read anything in any installation"
  is a different statement for a third-party subscriber than for you.
• If you would rather the Operator stay strictly hands-on-the-terminal as a product statement — that
  is a positioning call I cannot make, and it makes Option B correct and this issue closable.
• If the measured marginal cost were near the Coder arm's: it is not, by ~5 orders of magnitude.

Consequence of doing nothing: the Operator keeps answering honestly and uselessly; the A/B on
#433 keeps reporting a capability delta as a driver delta; and the standing instruction on this
instance ("we only work through GitHub issues") stays unexecutable whenever the machine is asleep.

---

Verified: the live tool set (MCP list_instance_tools); the token/cost figures above (/v1/usage,
30d, read today); the prompt-size delta (probe against the real registry + prompt builder); the
issue-payload size (live GitHub API, toSummary shape); the absent github constraint vocabulary;
16 installations; that 2dff5c62… is the only agent with slug tmux-operator; every file:line
quoted.
Inferred: that the model would actually call a granted github_list_issues in the turn it is
asked, rather than describing it — the assembled prompt is not observable through any API and I did
not spend the owner's key to find out. Step 1's behavioural check is still unrun for the same
reason.

[serge-ivo]

The open question in the brief above is now answered — it resolves in favour of Option A

The brief said the blocker on Option A was: "I could not establish how many subscribers exist
outside this account." Measured today:

• GET /v1/agents/2dff5c62…/analytics → "subscribers": 2
• my_instances → both are the owner's: cda75e28… ("Heartfull (tmux)") and 1a8486b5…
  ("tmux Operator"). There is no third party.
• GET /v1/agents (the public catalog, 15 agents) lists tmux-operator with status: "inactive" —
  so it is not being newly discovered either.

So the "read anything in any of 16 installations" objection is, today, "read anything in the owner's
own installations, on two of the owner's own instances". That was the stated condition for taking
Option C first; it does not hold.

One delivery risk the brief did not cover, checked

#496 ("a seed personality fix never reaches existing instances") makes it look as though a migration
on the agents row would not reach cda75e28… and 1a8486b5… without re-subscribing. For
capabilities that is not the case. capabilitiesForInstance
(workers/api/src/lib/agent-capabilities.ts:524-541) resolves live on every call:

SELECT a.slug, a.category, a.config
  FROM agent_instances i JOIN agents a ON a.id = i.agent_id
 WHERE i.id = ?1 AND i.user_id = ?2

a.config is read fresh, not copied at subscribe. So a WHERE slug='tmux-operator' migration on the
0117 pattern takes effect for both existing instances immediately, with no re-subscribe and no
backfill — unlike the identity/personality fields #496 is about. Worth stating in the migration's
comment so the next reader does not add an unnecessary instance backfill.

Fresh evidence from a second agent, same root cause

The Coder Lead transcript (filed as #503) contains the mirror of this one. On 11 Aug 01:29 the owner
said:

"Yes, all agents should be running and doing some open issues by priority order… Check if you have
access to their issues also, you should be able to at least read their issues and file them also in
the GitHub."

The Lead does hold github_list_issues/github_read_issue and that is exactly why it could keep
working. Three minutes later, asked which issue a subordinate was on, it offered: "I can check the
open issues on HeartFull-online/platform right now." That is the capability this ticket is about,
in use, on the same account, on an agent with surfaces: [] and no runner — which is the strongest
form of the brief's argument that GitHub reads are not a repo-surface privilege.

Meanwhile the Operator, asked the same class of question with its machine asleep, spent four turns
asking for a repo name it could not have used. The two agents differ by five entries in a JSON
array, and that difference is the whole of the owner's experience.

Nothing above changes the recommendation

Option A, unchanged: the five read-only github_* tools, migration on the 0117 pattern, flip
tmux-operator-seed.test.ts:133-139. github_create_issue stays off (#447). What has changed is
that the one recorded reason to prefer Option C first is now measured and absent.

[serge-ivo]

The open question is answered — and the answer moves the grant off this agent. Step 2 is superseded, not done.

The brief above asked whether the Operator is strictly hands-on-the-terminal or a driver that
needs to read the tracker from the cloud. The owner answered today, and he answered a slightly
different question than the one that was asked:

"check if TMUX coder agent also has access to Github or not? it was saying it doesn't. do we have
2 tmux agents? one for general TMUX operations and another specifically for coding? [the latter]
should have access to tmux and gh like our other coder agents do!!!"

He does not want the general Operator to grow GitHub. He wants the coding one to have tmux and
GitHub — and he believes the coding one already exists as a separate agent. It does not.

Filed as #515. It seeds a new published tmux-coder (7 tmux_* + the 8 github_* that
coder-repo holds after 0120/0121), and leaves tmux-operator alone.

Why the grant belongs on a new agent rather than on this one

Three things, all checkable:

1. He already wrote the tmux coder by hand. GET /v1/instances/cda75e28…/instructions on the
   instance in this ticket's transcript is a full coder spec — "You are the tmux-driven half of a
   cost comparison… You are the driver, not the coder… Count your turns… The Repo Coder enforces a
   merge_policy setting in code. You have no such enforcement, so it is a rule here instead."
   The distinction he is asking about exists; it is just being carried by prose.
   It is also stale: those rules tell the agent to call terminal_new_target,
   terminal_run_command, terminal_send_keys and terminal_capture — four names 0099 removed
   from this agent. It works only because the model substitutes the tmux_* neighbours.
2. Option A's blast-radius objection is worse for write than for read, and he asked for
   Coder-parity, which now includes writes. Since 0120 the benchmark is not five read tools, it
   is github_create_issue + github_comment_issue + github_update_issue as well. Putting three
   unbounded GitHub writes on the same agent that holds tmux_run_command's arbitrary shell — on the
   one published Operator that [design] tmux is the one Operator connector with no capability ceiling — CONNECTOR_CONSTRAINTS has a single key, and #403 moved the published agent off it #447 recorded as having no capability ceiling, with github still
   absent from CONNECTOR_CONSTRAINTS and 16 App installations reachable — is a different
   proposition from the read-only grant this brief recommended. A separate agent scopes it to the
   instance he uses for coding.
3. It keeps the guard this ticket built. lib/tmux-operator-seed.test.ts:133-139 asserts the
   Operator has no github_* tool, with a comment saying that assertion is where a future grant
   "becomes visible instead of silently making the guard below vacuous". Under [design] There is no tmux Coder — the coding half of the tmux split lives in one instance's Rules box, and has no GitHub tool. Seed tmux-coder with tmux + the Coder's GitHub set #515 it stays true
   and keeps guarding. Under step 2 as written it has to be deleted.

One owner, so this is explicit

#515 owns every GitHub-on-tmux grant, including the option of also giving tmux-operator the
five read-only tools — that is one extra UPDATE in the same migration and is written up there as
the owner's call, with a recommendation against it. Nothing about that grant should be implemented
from this ticket.

What is left here

Nothing to build. Step 1 (TOOL_LIST_CLOSED) shipped in 4031cbe and is verified live: the
Operator's honest "I can only reach GitHub through your machine" is now not only true but
complete, because the agent that can reach GitHub will exist.

Recommend closing this on the commit that lands #515, with a closing note pointing at it. The one
piece of unfinished business named in the earlier comments — the behavioural check that
TOOL_LIST_CLOSED actually reaches a live turn — is worth running once on cda75e28… before
closing: ask "what GitHub issues are open?" with the runner offline; it must say it cannot reach
GitHub and must not ask for a repo name.

Corrections to my own earlier comments on this ticket

• The recommendation to grant on tmux-operator stands as analysis and is superseded as a
  decision. The measured cost figures (+168 tokens/turn, ~1,540 tokens per issue read, $2.61/30d
  for this agent) carry over to [design] There is no tmux Coder — the coding half of the tmux split lives in one instance's Rules box, and has no GitHub tool. Seed tmux-coder with tmux + the Coder's GitHub set #515 unchanged.
• "Re-baseline the cost comparison when you grant" applies with more force now: [design] There is no tmux Coder — the coding half of the tmux split lives in one instance's Rules box, and has no GitHub tool. Seed tmux-coder with tmux + the Coder's GitHub set #515's arm is a new
  instance, so the tmux arm of [docs] "Can I use tmux for coding?" has no correct answer in the docs — the architecture split is documented, the user-facing choice and its unmetered cost are not #433 restarts from zero rather than shifting mid-run. That is the
  cleaner experiment, not a cost.

[serge-ivo]

Filed #517 as the sibling case step 1 leaves open, rather than reopening this one.

TOOL_LIST_CLOSED (lib/connector-tool-prompt.ts:131-139, 4031cbe) already carries the exact sentence — "do NOT send the owner to Settings for it, because this toolset is fixed by the agent's definition and is not a switch they can flip" — but its stated trigger is "A system that is NOT on it". When a tool the agent does hold is refused at the gate, the model is outside that sentence, and it invents a remedy anyway: reproduced 5/5 today against a deployment that already carries this fix, on two agents and two connectors, including a first turn on an empty conversation. The refusal it was handed contains the correct remedy verbatim, in full (24,000-char model-side cap vs a 405-char message), and the reply replaced it with "go to Settings → Connections and connect a tmux instance", which is an action no console screen offers.

Same class, different door — the absent-tool case is closed, the refused-tool case is not.