[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

[serge-ivo]

Reported

"I updated it, but it is still using the old one. Why?"

Because nothing you can reach changes a repo's folder. The path is displayed, never edited.

Measured

The console shows it as read-only text. agents/coder/web/src/RepoSettingsModal.tsx:86:

{repo.workdir && <Detail label="Folder" value={repo.workdir} />}

Detail is a display row — it sits between Clone status (:87) and Repo id (:88), both
obviously read-only. The modal's actual inputs are name (:77), dev / staging / prod URLs
(:103-107) and instructions (:57). The Folder line looks like a field and is a label.

The API has no parameter for it either. routes/coding-repos.ts:500:

const body = … as { name?: string; urls?: {…}; mergePolicy?: string };

workdir is not in the payload type, not read, not passed to updateRepo. So there is no request
that changes it — the console is not failing to send one, there is nothing to send.

Verified live: Chess coder's repo still reads workdir: ~/dev/pas/platform/apps/chess-academy,
updatedAt: 2026-08-07 23:23:15 — unchanged after the owner edited what they reasonably believed
was the path.

Why this matters more than a missing input

It is the second half of #405. That ticket makes ready a checked claim at ADD time. This one
means a repo that is wrong — or that becomes wrong when a checkout moves, which is the ordinary case
— can never be corrected, only deleted and rebuilt.

And deleting is not free. A repo row carries its name, its dev/staging/prod URLs, its merge policy
(#314), its per-repo instructions, its issue-mode configuration, and it is the foreign key for
coding_sessions and the timeline. "Just delete and re-add" asks the owner to throw all of that
away to fix a typo in a path.

The agent, meanwhile, is doing everything right and is stuck: it reports "repo_tree found no files
at ~/dev/pas/platform/apps/chess-academy … check the Coding tab to confirm the runner is pointing at
the right directory" — advice that cannot be followed, because the Coding tab has no such control.

Do

• Accept workdir on PUT /:instanceId/coding/repos/:repoId, validated the same way the
  add path validates it after [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 — an edit must not be able to install a path that a create
  would refuse.
• Make the Folder row an input in RepoSettingsModal, with the validation result shown
  inline: this is exactly the moment to say "that directory is empty" rather than after the
  agent hits it.
• Re-run the check on save, and clear cloneStatus: needs_attention when the new path is
  good — the status is a claim about the current path, so it must move with it.
• Consider the same for provider/defaultClient if they are similarly display-only; the audit
  that finds one read-only-field-that-looks-editable should look for its siblings.

Acceptance

• An owner can correct a wrong folder without deleting the repo, keeping name, URLs, merge
  policy, instructions and session history.
• A folder that does not exist / is empty / is not a git work tree is refused on EDIT, with the
  same message the add path gives.
• cloneStatus reflects the new path immediately after a successful edit.

Files: agents/coder/web/src/RepoSettingsModal.tsx:86,
workers/api/src/routes/coding-repos.ts:500-519, workers/api/src/lib/coding-store.ts (updateRepo).
Related: #405 (validation at add time — this is the missing edit half), #325 (the family of
"settings that said saved").

[serge-ivo]

Two findings that sharpen this, from the owner asking "why is it editable on the UI then?"

1. It is not editable — it is styled like every input in the app

Detail (RepoSettingsModal.tsx:121-128) renders a plain div:

<div className="bg-paper border border-line rounded-lg p-2 min-w-0">
  <div className="text-2xs uppercase … text-muted-soft">{label}</div>
  <div className="text-xs text-ink break-words font-mono">{value}</div>
</div>

Compare the add-repo input two components away (ReposList.tsx:200):

bg-panel border border-line rounded-xl px-3 py-2 text-sm

Same border token, same radius family, same padding scale, and the Folder value is font-mono — which in this console is the treatment reserved for path/command INPUTS. The only difference is bg-paper vs bg-panel: #0a0a0a against #141414, on a dark-only theme. That is not a distinction a user can see.

So a read-only value is wearing the app's text-field costume, in a modal whose top control genuinely IS a text field (Name). Clicking it does nothing and there is no cursor, which reads as the app being broken rather than as the field being static. Worth fixing independently of the API change: a read-only detail should not be visually indistinguishable from an input. That is a #366/#367 question as much as this ticket's.

2. For a single-repo agent there is NO path control at all — not even delete-and-re-add

ReposList.tsx:192:

{showAddRepo && !singleRepo && ( …the add-repo input… )}

The reported instance is Chess coder (26f71cd8), whose capabilities are:

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

So the add-repo input is hidden by design (correct — a Repo Coder owns one repo), and the Folder is read-only. The only remaining route to a correct path is to delete the repo entirely and hope the add form reappears at zero repos. For the agent shape the platform is actively moving toward (#187's supervised Repo Coder), a mistyped path is unrecoverable without destroying the row.

That raises the priority of the edit path in this ticket: for repos: "single" it is not a convenience, it is the only possible remedy.

[serge-ivo]

Delivered — fc01c17, in the same commit as #411

Closing as delivered, not as superseded. #411 supersedes this ticket's framing, but the two are one fix and it was done once, covering both halves:

This ticket's half — PUT /v1/instances/:instanceId/coding/repos/:repoId now accepts workdir (it was not in the payload type, not read, not passed to updateRepo, which is why the console "was not failing to send one — there was nothing to send"). The Folder row in RepoSettingsModal.tsx:86 is a real input instead of a Detail display row, with the validation verdict rendered inline. The check re-runs on save and cloneStatus moves with the path. Validation reuses #405's verifyLocalWorkdir/checkWorkdirVia, so — as this ticket required — an edit cannot install a path that a create would refuse.

#411's half — the duplicate home (settings.repo) is deleted rather than wired, per the owner decision, so there is now exactly one place a repo's address is written down.

Acceptance

• An owner can correct a wrong folder without deleting the repo — name, URLs, merge policy, instructions and session history are untouched; the row stays the FK for coding_sessions and coding_timeline.
• A bad folder is refused on EDIT with the same message the add path gives — with one deliberate refinement from [design] "Which repo does this agent work on" is stored twice — the field you can edit is read by nothing, and for a single-repo agent there is no supported way to fix a wrong path #411's comments: a path that is merely unverifiable (runner offline) is stored and marked needs_attention, not rejected, because the owner may be configuring from a phone with the laptop shut. A genuinely invalid one — "" — is refused outright.
• cloneStatus reflects the new path immediately. This is why I used onUnverified: "unknown" rather than the null in [design] "Which repo does this agent work on" is stored twice — the field you can edit is read by nothing, and for a single-repo agent there is no supported way to fix a wrong path #411's implementation notes: null would leave the old path's ready on the new path, which is exactly the false claim [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 removed. Flagged on [design] "Which repo does this agent work on" is stored twice — the field you can edit is read by nothing, and for a single-repo agent there is no supported way to fix a wrong path #411 in case you want it the other way.
• New: a 409 when a session is live and the path actually changes (returning sessionId), so an engine process whose cwd is the old path cannot be silently re-pointed — the split-brain risk raised in [design] "Which repo does this agent work on" is stored twice — the field you can edit is read by nothing, and for a single-repo agent there is no supported way to fix a wrong path #411's self-review. A no-op resave is not refused.

Verified in production

PUT /v1/instances/bfc76603…/coding/repos/repo_a452fe0f… {"workdir":""}
  → HTTP 400 {"error":"A folder is required. To remove this repo, delete it."}

Before this commit the identical request was a silent 200 no-op, because workdir was not in the payload type — so the 400 is the direct evidence the parameter is now read. No production data was mutated by the check.

Full bar green (6354 tests, Chromium + WebKit e2e, migration hygiene, file-size and control-shape ratchets unraised); CI and both worker deploys succeeded. Details, the provider/defaultClient finding, and what is not visually verified are on #411.