[bug] Every Repo Coder subscribed since 2026-08-08 has no working repo_* tool — migration 0102 removed the setting the tools still read, and said no code read it

[serge-ivo]

Every Repo Coder subscribed since 2026-08-08 has no working repo_* tool

Migration 0102_coder_repo_drop_repo_setting.sql removed repo from coder-repo's settingsSchema and stated, at line 30:

"With the field off the schema the console stops rendering it, applySettingsPatch (schema-driven) can no longer write it, and no code reads it — it is inert."

The last clause is false. workers/api/src/lib/connectors/repo-local.ts:35:

export const REPO_PATH_SETTINGS = ["repo_path", "repo"] as const;

repoPathForInstance (:69, loop at :79) reads agent_instances.config.settings for those keys and nothing else, and :178 — const workDir = await repoPathForInstance(ctx); — is the only workdir source for all six repo_* tools (repo_tree, repo_read_file, repo_git, repo_remote, and since #508 repo_find, repo_grep).

So the setting is unwritable and still required

applySettingsPatch (workers/api/src/lib/instance-settings.ts:71-92) iterates for (const field of schema), so a key absent from the schema cannot be written. resolveSettingsValues (:28) filters reads the same way.

Net effect for a coder-repo instance created after fc01c17 (2026-08-08 04:05 UTC):

• the console renders no control for it,
• the API cannot accept a value for it,
• and six tools require it.

Live proof it is already breaking instances

FIS coder 5d14a2e1-140c-466d-beec-ddd331a1e72b, created 2026-08-10 — i.e. after the migration. Its entire conversation history is one failed call:

❌ repo_remote — "No repository is configured for this agent."

By contrast both Chess instances predate the migration and kept their stored values: Chess coder 2 bd43f4de… works, and Chess coder bfc76603… holds the wrong path that 0102's own header quotes as the original bug report — and it cannot be corrected from the UI, which is why that instance is dead.

get_instance_settings(bd43f4de) returns only engine / autonomy / merge_policy; the repo path is invisible even where it exists and works.

#513's fix assumed the opposite, and reintroduced the class

#513 (closed, c6eaf74) fixed a message that named the wrong control. Its body asserts:

"A coder-repo instance has a different field, labelled "Repository" (migration 0063)"

True before 0102, false since. Post-fix, repo-local.ts:142 finds no matching schema field, hint.label falls back to "the repository setting", and repoMissingMessage (:172) still ends with "in the console (Settings → Agent settings)" — a card that has no such control. So the agent still directs the owner to a control that does not exist, which is the same defect class as #513 and #517, reintroduced by #513's own premise.

What a fix has to decide

0102's intent was right — the bug it fixed was real (a setting and a coding_repos row disagreeing, with the one-way wire firing only on CREATE). The error is that it removed the input while leaving the reader. Three possible shapes:

1. Point repo_* at coding_repos.workdir — the row the Coding tab already manages, which is where the truth now lives. Most consistent with 0102's reasoning; needs a decision about which repo when an instance has several (surfaceOptions.coding.repos:"single" bounds it for coder-repo).
2. Restore the schema field and re-establish the wire both ways. Undoes 0102 and re-opens the divergence it closed.
3. Keep the field off the schema but give repoPathForInstance a writable path — smallest change, but leaves two sources of truth, which is exactly what 0102 was fixing.

(1) looks correct, but this is a decision about where a Repo Coder's repo lives, so it should be made deliberately rather than by whichever edit is smallest.

Acceptance criteria

1. A coder-repo instance created today can be given a repository through the console, and its repo_* tools work.
2. FIS coder 5d14a2e1 specifically becomes usable — it is the live casualty and the acceptance test.
3. Instances created before 0102 keep working with no manual migration (Chess coder 2 must not regress).
4. repoMissingMessage names a control that exists, or says plainly that none does — the [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 #513/[bug] A refused tool's own remedy is discarded and the agent invents "Settings → Connections" — reproduced 5/5, and the transcript truncates the real remedy away #517 rule.
5. A test binds the reader to the writer, so a future schema edit cannot orphan a required setting again. This is the second time a "no code reads it" claim in a migration comment turned out to be wrong; the guard is what stops a third.
6. 0102's comment is corrected — its claim is load-bearing and untrue. Note check-migrations --require-history permits a comment-only edit precisely for this case.

Verified vs inferred

• Verified: REPO_PATH_SETTINGS at repo-local.ts:35, the schema-driven write at instance-settings.ts:71-92, 0102's text, FIS coder's failing history, both Chess instances' states, and get_instance_settings output.
• Inferred: that every post-0102 coder-repo instance is affected. One is confirmed (FIS coder); the mechanism implies the rest, and no counter-example was found.

[serge-ivo]

Fixed in ede0403, deployed, and verified against FIS coder in production.

What shipped

repoPathForInstance resolves the folder the console can actually edit — shape (1) in the issue:

1. the most recently updated coding_repos row whose folder nobody has faulted;
2. else the pre-0102 typed setting (REPO_PATH_SETTINGS);
3. else the faulted row anyway, so [bug] A local repo is marked "ready" without anyone checking it exists — an empty checkout reports success, and the agent invents the code it cannot see #405 still diagnoses the path — and it is the path [bug] A repo's folder cannot be changed — the console shows it as read-only text and the update API has no parameter for it, so a wrong path can only be deleted #410 made editable — instead of "no repository is configured".

Step 2 exists because of something measured, not reasoned. bfc76603 (Chess coder) is not dead — it works today, off its orphaned setting, while its row points at ~/dev/stores/pas/platform/apps/chess-academy, which the runner reports does not exist. A flat row-first reader would have taken a working instance to a broken one, which is criterion 3's whole point. clone_status = 'needs_attention' is allowed to decide this because it is a measurement, not a default: cloneStatusForVerdict writes it only from a definite runner verdict and returns null for unverified, so an offline or too-old runner never demotes a good row.

local-repo-chat is untouched — measured live, it has zero repo rows and its repo_path field is still on its schema, so the fallback remains its only source.

Criterion 2 — FIS coder 5d14a2e1, the acceptance test

Its row had no folder at all, so the fix alone could not make it work; what the fix changed first is that the refusal finally names the control that exists:

No repository is configured for this agent. The repository "～/dev/stores/fis/platform" is already on this agent's Coding tab, but no folder on your machine is recorded for it — that is why there is nothing to read. Open that repository's settings in the Coding tab and set its folder to the checkout… Fix the repository that is already there rather than adding a second one.

I then did exactly that through #410's owner flow (PUT …/coding/repos/:repoId {workdir}), setting ~/dev/stores/fis — the runner shows fis/platform does not exist and fis is the repo. The runner verified it (clone_status: ready). All six tools now work:

repo_git status  → ## main...origin/main
repo_tree        → DEPLOY.md, packages/, platform-docs/, scripts/ …
repo_remote      → origin: git@github.com:freeideastore-online/platform.git
repo_read_file   → --- package.json ---  { "name": "@fis/platform" …
repo_find        → package.json, packages/mcp/package.json, packages/worker/package.json

repo_remote confirms the folder is the right one. Note the data change: I set that repo's folder on your instance as part of this verification — revert it in the Coding tab if you meant a different checkout.

Criterion 3 — no regression, verified instance by instance

repo_git status on every instance declaring repo_*, before and after the deploy. All eight that worked before still work: Chess coder 2, Chess coder bfc76603, Heartfull, PAS Coder, FWS/FGS/FAS platform, and Cordouan Health (local-repo-chat). The ninth was FIS coder, above.

Criteria

1. ✅ 2. ✅ 3. ✅ 4. ✅ names the Coding tab, the repo, and tells the owner to fix the row he has; the github escape hatch and the owner/name coordinate clause are preserved; an agent with no control at all says so plainly instead of inventing one. 5. ✅ repo-path-writer.test.ts, two legs — every seeded agent declaring a repo-local tool must have a writer, and that writer must be one repoPathForInstance actually consults. Leg 1 alone would have stayed green throughout this bug, since coder-repo had the Coding tab all along and the reader ignored it; leg 2 is what closes that. Negative-verified by removing repo_path from 0066's seed. 6. ✅ 0102's comment corrected in place, DDL byte-identical (check-migrations --require-history passes; 0080 is the precedent).

Still open, needs its own issue

FIS coder's row was created with provider: local, clone_status: ready and no workdir — a combination createRepo cannot produce (coding-store.ts:136 sets ready only when a workdir was supplied), and neither updateRepo nor updateRepoClone can null one out (both COALESCE). Its name carries a fullwidth tilde (U+FF5E), so something accepted a mistyped local path and stored a folder-less row while claiming ready. The path that produces it was not traced and should not be guessed at — it needs pags-ba to trace the add-repo route and the MCP coding_repo_add tool. Until then a repo can appear on the Coding tab, look ready, and be unreadable.