[bug] An unconfigured Repo Coder tells the owner to set "Repository path" — a field that agent does not have — and declines GitHub work that needs no repo at all

[serge-ivo]

An unconfigured Repo Coder sends the owner to a control that does not exist, then declines work it could do

FIS coder (5d14a2e1-140c-466d-beec-ddd331a1e72b, agent coder-repo), 2026-08-11 01:34 — the
instance's entire history, three messages:

owner — "What are the EAP open issues for this repository, for this project?"

❌ repo_remote — "No repository is configured for this agent. Set "Repository path" in the console (Settings → Agent settings) to the chec…"

agent — "No repository is configured for this agent yet. Until a local checkout path is set under Settings → Agent settings, I can't read the file tree, run git commands, or look up issues tied to a specific repo. … Once that's set, I'll be able to: Identify the GitHub remote (owner/repo); Query open issues filtered by an "EAP" label; Cross-reference them against the actual code."

Two defects in four lines, and the agent has not been used since.

1. The control it names is not the control that exists — verified

The sentence is hardcoded at workers/api/src/lib/connectors/repo-local.ts:81:

error: `No repository is configured for this agent. Set "Repository path" in the console
        (Settings → Agent settings) to the checkout on your machine, e.g. ~/work/my-repo.`,

"Repository path" is local-repo-chat's field label
(migrations/0066_seed_local_repo_chat_agent.sql, {"id":"repo_path","label":"Repository path",…}).
A coder-repo instance has a different field, labelled "Repository"
(migrations/0063_seed_coder2_agents.sql, {"id":"repo","label":"Repository","type":"text", "description":"The repo this agent owns — a local path (~/dev/my-repo) or owner/name."}).

The connector reads both keys on purpose — REPO_PATH_SETTINGS = ["repo_path", "repo"]
(repo-local.ts:35), with a comment saying the two agents "name the same thing differently and
neither should be renamed". The message did not get the same treatment: it states one label for
both. So the owner is told to look for a setting that is not on his screen. The message is also the
only guidance he gets, because a coder-repo with no repo has nothing else to show him.

2. It declines the GitHub half, which needs no repo setting

github_list_issues takes repo as a tool argument — {repo: "owner/name", state, labels}
(workers/api/src/lib/connectors/github.ts:170-180) — and is allowed: true on this instance. The
local checkout is only how the agent discovers the coordinate (repo_remote); it is not required
to use it. Asked for "the EAP open issues", the honest answer was "I don't know which repo I own —
tell me the owner/name and I'll list them now", which is what #493 is about in its own words. What
it said instead was that it can't look up issues, which is not true, and it then described the
label-filtered query it would run once the path is set — describing a capability it has right now
as blocked on something unrelated.

What to do — cheapest first

1. Make the refusal name the field this agent actually has. resolveTarget already knows which
of repo_path / repo it looked for; carry the settings label with it (read from the agent's own
settingsSchema, which is where the truth is) and interpolate. Fallback to "the repository setting"
rather than a hardcoded guess — a message that names no control beats one that names the wrong one.

2. Say what still works in the same breath. The refusal should end with the GitHub escape hatch,
because that is the whole of what this agent can do unconfigured: "You can still ask me about
GitHub issues, pull requests and CI if you tell me the repository as owner/name." One sentence,
in the same string, so the model cannot separate the "no" from the "but".

3. Consider deriving the coordinate from the setting when it is already owner/name. The
coder-repo repo field explicitly accepts "a local path (~/dev/my-repo) or owner/name", and
repoPathForInstance deliberately skips the owner/name case as "not a checkout, which is honest"
(repo-local.ts:57-60). Honest for the local tools; but in that state the GitHub tools have the
coordinate the owner already typed and still make the model ask for it. Feeding it into the GitHub
tools' repo default is a separate, small change — flagged, not bundled.

Alternatives considered and rejected

• Rename one of the two settings so the message is true. Rejected by the connector's own comment
  (repo-local.ts:26-33): they are two different agents' vocabularies and renaming either is a data
  migration on live instances.
• Drop the label from the message entirely. Acceptable as a fallback, weaker as the fix — "set
  the repository setting" is less useful than the right label when the right label is available.
• Fix it in the prompt instead. Rejected: the wrong string is in the tool result, which is the
  most authoritative thing the model reads on that turn. A prompt telling it to distrust its own
  tool results is the wrong shape of fix.

Acceptance criteria

• On a coder-repo with no repo set, repo_tree / repo_read_file / repo_git / repo_remote
  all refuse with a message naming "Repository"; on a local-repo-chat, "Repository path".
• The label comes from the agent's settingsSchema, so a third agent adopting the connector gets
  its own label with no code change.
• An agent in that state, asked about issues, asks for owner/name and then answers — it does not
  say it cannot look up issues.
• A test covers both agents' refusal text, since the whole defect is that one string served two.

Regression risk

• A settings read on a refusal path. The refusal currently costs nothing; reading the schema adds
  a query to a path that fires when something is already wrong. Cache it with the capabilities read
  that turn, or accept it — it is bounded by how often an agent is misconfigured.
• Point 2 makes the model over-eager to ask for a repo name. Bounded: it should ask once and only
  when it has no coordinate, not on every turn. Worth an assertion.

[serge-ivo]

Fixed in c6eaf74 (on main, CI green, API Worker deployed).

The label now comes from the agent's own settingsSchema, so a coder-repo is told to set "Repository" and a local-repo-chat "Repository path" — and a third agent adopting the connector gets its own label with no code change. Where there is no schema to read it says "the repository setting": naming no control beats naming the wrong one. Renaming a setting stays rejected for the reason the connector's own comment gives.

It no longer declines the GitHub half. The escape hatch is in the SAME string, so the model cannot separate the "no" from the "but", and it is worded to ask once and only when it has no coordinate — the regression risk you flagged.

One correction to the proposal, worth recording. The escape-hatch sentence is CONDITIONAL, not unconditional. local-repo-chat — the other agent on this connector — declares four repo tools and no GitHub tool at all (0066, unchanged). An unconditional promise would have moved the false claim to the other agent rather than fixed it. Only an EXPLICIT capabilities.tools declaration counts, because an agent declaring nothing resolves its tools server-side and promising what cannot be confirmed here is the same mistake in a new place.

Point 3 taken, narrowly. When the setting already holds owner/name, the message says so and hands the coordinate over — that is part of making the refusal honest, and it is the difference between "I don't know which repo" and "I know which repo, I have no local copy". NOT taken: feeding it into the GitHub tools' repo default, which is the separate change you flagged and touches another connector.

Acceptance criteria.

• Both agents refuse with their own label, through all six local tools (asserted per tool).
• The label comes from settingsSchema; an invented third agent's label is asserted.
• It states the GitHub capability instead of denying it — where the agent actually has it.
• A test covers both agents' refusal text; repoMissingMessage is pure so both halves are asserted without a database. 8 new tests, 46 in the file.

Regression you named: one extra read on the refusal path, accepted for the reason you give — it is bounded by how often an agent is misconfigured.

Not verified live. Reproducing the exact refusal needs an unconfigured instance and an authenticated session; the FIS coder instance was not touched. Verified through the deployed code path and its tests, not through a live turn.