[bug] A Repo Coder is not told it owns a repo — ownership lives in a memory string, and it cites tabs it does not have

[serge-ivo]

The gap

A Repo Coder is configured to own exactly one repository:

"surfaces": ["coding"],
"surfaceOptions": { "coding": { "repos": "single", "drive": false, "copilot": false } }

repos: "single" is read only by the console (lib/surfaces.tsx, to hide add-repo and the
multi-repo list). It never reaches the system prompt. What the model gets instead is
## Attached Repositories (agent-think.ts:365) — an inventory of what happens to be attached,
phrased as context, not as responsibility.

So the agent's sense of owning a repo comes from a seeded memory string (goal = "Deliver the
objectives you are given in your repository…"), not from its declared capabilities. That is why it
can describe itself correctly one day and contradict its own configuration the next: memory is
narrative, capabilities are fact, and only the narrative is in the prompt.

Evidence it does not know its own configuration

FAS platform Coder (964594b6), 2026-08-04, asked what it can do:

To get started, attach a repository in the Repo tab and give me an objective.

This agent has no Repo tab. That surface is gated to surfaces: ["repo"] (lib/surfaces.tsx)
and it declares ["coding"]. It invented a UI location it cannot have, and told the user to go
there.

Same class as the toolBlurbFor docstring already warns about — "it tells the model a story about
itself that its actual tool set contradicts, and the model believes the story" — except here the
story is about surfaces and repo ownership rather than tools, and nothing derives it.

Why it matters beyond a wrong tab name

The product promise is "a workspace == an agent instance" — an agent responsible for a repo. The
implementation is a chat brain that can delegate to a separate executor via start_work, with no
declared statement of what it owns. Consequences already observed:

• It points users at surfaces it does not have (above).
• It cannot reason about being single-repo, because nothing tells it — e.g. it has no basis to
  refuse or question an instruction aimed at a different repository.
• Combined with [bug] The prompt still forbids what start_work does — a Coder denied real work and told the user to redo it #254, its self-description is unreliable in both directions.

Suggested shape

Derive the self-description from the resolved capabilities, the way toolBlurbFor derives the tool
blurb:

• surfaceOptions.coding.repos === "single" → state it plainly: "You are responsible for exactly
  one repository: <owner/repo> at <workdir>. You do not manage other repositories and cannot add
  one."
• Name only surfaces the agent actually declares, so it can never send a user to a tab that is not
  rendered for it.
• Keep the seeded goal memory for tone/purpose, but stop letting it be the only source of a fact
  the capability registry already knows.

Verification

• A single-repo Coder names its repo when asked what it works on, without reading memory.
• No agent ever references a tab absent from its declared surfaces.
• An agent with no repo attached says so and names the correct place to add one for its own
  configuration.

[serge-ivo]

Verified TRUE on every claim. Fixed in 27f4c4e.

Checked each:

• repos:"single" reached only two consumers — agent-do-tools.ts (for drive, not repos) and routes/coding.ts (copilot/drive). Grepping optionsFor confirms nothing ever passed repos to the prompt. Console-only, exactly as stated.
• Ownership really did live in the seeded goal memory string (migration 0063: "Deliver the objectives you are given in your repository…").
• ## Attached Repositories (:359) is phrased as inventory, not responsibility. Correct.
• The invented Repo tab is real, and I found where it comes from — see [bug] The prompt still forbids what start_work does — a Coder denied real work and told the user to redo it #254. coder-repo seeds guardrails.responseStyle:"technical", and the prompt used that string as its test for "is Repo Chat", so a Repo Coder was served the Repo Chat block containing suggest adding the repo in the Repo tab. It was not the model inventing a tab from nothing; the platform told it to say that.

What shipped

selfDescriptionPrompt in the new lib/agent-self-description.ts, emitted as a ## What you are block, all derived:

• surfaceOptions.coding.repos === "single" → "You are responsible for exactly ONE repository: platform (org/platform) at ~/dev/…. You do not manage any other repository and cannot add one."
• No repo yet → says so, and names its own place to set one (Settings → Agent settings) — never the Repo tab.
• tabsFor(capabilities) mirrors store/console/src/lib/surfaces.tsx and emits "Your console has exactly these tabs: … NEVER refer the user to any other tab — if a tab is not in that list, it does not exist for you, and sending them there is a wrong answer." Tested: tabsFor(coder-repo) contains Coding and not Repo; tabsFor(repo-chat) is the reverse.
• Bonus the ticket did not ask for, but which falls straight out of having both facts: when the repo setting and the attached repo disagree, it says so rather than picking one. repoMatchesSetting is deliberately loose (~/dev/foo matches owner/foo) so the note stays rare enough to be believed.

The seeded goal memory is untouched, per your suggested shape — it keeps carrying tone; it just is not the only source of the fact any more.

One honest caveat: tabsFor is a second copy of the console's show predicates. It cannot be shared — the registry entries are React components in the console bundle and the Worker cannot import them — so what is shared is the decision, which is a pure function of surfaces + tools. Tests pin the result for all five first-party shapes, so a divergence fails CI rather than surfacing as an agent naming a tab that is not there. If the registry gains a tab, that table needs the same entry.