[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

[serge-ivo]

The agent is not lying about the code. It is lying about a repo that isn't there.

Chess coder (26f71cd8) has fabricated tool results on nearly every turn for two days. #395's
guard now catches it. This is why it keeps happening.

Measured

The instance's only repo:

GET /v1/instances/26f71cd8…/coding/repos
  name:        apps/chess-academy
  provider:    local
  workdir:     ~/dev/pas/platform/apps/chess-academy
  cloneStatus: "ready"          ← the platform says this repo is usable
  createdAt:   2026-08-07 08:29:04Z

On the machine:

$ ls -la ~/dev/pas/platform/apps/chess-academy
  total 0                      ← empty. 0 files.
  drwxr-xr-x  2 …  7 Aug 18:29 .        ← created 18:29 AEST = 08:29 UTC, the minute the row was created
$ git -C … remote -v
  fatal: not a git repository

The directory exists, contains nothing, and is not a git repo. It has been ready since the moment
it was added.

The chain, in three steps

1. A local path is accepted without anyone looking at it. routes/coding-repos.ts:92-104 — the
add-repo handler takes body.localPath, trims it, calls createRepo(... provider:"local") and
returns 201. There is no check that the path exists, is non-empty, or is a git repository. The
runner is connected at that moment and could answer all three; it is never asked. cloneStatus
becomes ready, which is the same word a successfully cloned repo gets.

2. Every read tool then reports the absence as SUCCESS. lib/connectors/repo-local.ts:

:127  return { content: lines.length ? … : "(no files found at that path)", success: true };
:217  return { content: res.remote ? … : "(no git origin remote — this checkout has no configured remote)", success: true };

Both are true sentences about an empty subfolder, and both are indistinguishable from one. Nothing
in either says the configured workdir is empty, nothing names the path, nothing is success:false,
and nothing reaches the console as a repo-level problem — the repos list still shows ready.

3. The agent is cornered on every turn. Asked "can email/password sign in be used in this app",
it calls the right tools, receives two non-answers that describe no problem, and has nothing to
relay. There is no diagnosis to pass on, so it invents the repo, the issues, and the file contents —
which is exactly the transcript in #395.

Why this is the fix that matters

#395's guard is downstream and it is working — the live transcript now carries
"The agent wrote tool results that no tool produced. They were removed…". But the guard removes an
invention; it does not remove the reason for one. As long as an agent is pointed at an empty
directory the platform calls ready, every question about that code has no honest answer available
to it, and a model under that pressure will keep filling the gap.

Do

• Validate a local path at add time, on the runner that will use it: does it exist, does it
  contain files, is it a git work tree? Reject or mark it needs_attention — do not write
  ready for a path nobody has looked at. ready is a claim; make it one the platform checked.
• Re-check on use. A checkout can be moved or deleted after it is added, which is the same
  state arriving later. The repos list should show it.
• Make the tool results diagnose, not shrug. For a configured workdir that is empty or is
  not a git repo, say so, name the path, and return success:false — an agent can relay
  "the configured checkout ~/dev/…/chess-academy is empty; the repo may have moved". It
  cannot relay "(no files found at that path)", and that difference is the whole ticket.
• Surface it on the Coding tab, beside the repo, with the remedy — the same treatment [bug] The Terminal tab learns the runner is gone only by failing — and blanks that error every 4s, so a phone shows an empty pane and a flicker #378
  gave the Terminal tab's offline runner.

Acceptance

• Adding a local path that does not exist, is empty, or is not a git repo does not produce a
  ready repo.
• repo_tree / repo_remote / repo_git against such a workdir return success:false with a
  message naming the path and the condition.
• The console shows the repo as unusable, with what to do.
• A legitimately empty subfolder of a real checkout still reports "(no files found at that
  path)" and stays a success — the two cases must not be conflated in the other direction.

Files: workers/api/src/routes/coding-repos.ts:85-104, workers/api/src/lib/connectors/repo-local.ts:127,217,
packages/browser-runner/src/coding/repo.ts. Related: #395 (the guard that catches the symptom),
#398 (the format that teaches the shape), #378 (the precedent for diagnosing rather than failing).

[serge-ivo]

Shipped in 5527cea, with the CLI bump in 6f8ce17. @proagentstore/cli@0.4.42 is published — verified on npm — so the runner half is actually reachable rather than merely committed. API deploy green.

The chain, closed at each of the three steps:

1. Add-repo now asks. New checkWorkdir on the runner (POST /coding/repo-check) reports exists / entryCount / insideWorkTree as three separate facts, because the remedies differ. Work-tree membership is git rev-parse --is-inside-work-tree, not an existence test on .git — ~/dev/monorepo/apps/thing is a legitimate workdir and an existence test would have condemned every package in every monorepo checkout. It also reports gitChecked, so a machine without git on PATH cannot condemn its own repos. Broken → 201 with needs_attention + warning (the row is still the handle you need to fix or delete it); no runner connected → unknown, never a silent ready.
2. Re-check on use — the repos list re-checks every read (parallel, capped at 12 local repos, 5s timeout, writes only on change). An offline machine leaves stored verdicts alone at list time and cannot mint ready at add time.
3. The read tools diagnose. repo_tree/repo_remote/repo_git/repo_read_file consult the workdir root only once they have already produced nothing, and return success:false naming the path and the condition.

The fourth acceptance criterion is honoured by construction: the root is what gets checked, never the tool's path argument — so an empty subfolder of a real checkout still returns "(no files found at that path)" as a success, byte-for-byte unchanged. Both halves of that trap are tested, as is the CLI-skew case (an old runner's 404 must not condemn a repo).

Console: unusable joins the existing reconciliation in repo-status.ts rather than becoming a fourth surface that guesses — it yields to a visibly in-progress turn and to an offline machine, and outranks active, because a session over an empty directory is not activity.

Verified: typecheck, 6014 tests (86 in the touched/added files), biome, design tokens, migration hygiene, plus Playwright at 320px and 390px in both Chromium and WebKit for the new #405 block. No migration — clone_status is a string column and needs_attention is an additive union member.

Not verified live: the observable behaviour needs a machine running pags up on 0.4.42. The check is: add a local path that is empty or missing and confirm the row does not say ready; then ask the agent about the code and confirm it relays the diagnosis instead of inventing it.

Follow-up worth filing: agent-think.ts renders repo status for the chat context with a three-way ternary, so needs_attention falls through as the bare string — the model sees — needs_attention rather than the diagnosis. Honest, and a large improvement on ready, but it should carry cloneError.

[serge-ivo]

Verified — but NOT closing: the fix is inert in production until the CLI on both machines is upgraded

Independent verification of 5527cea + 6f8ce17 (CLI 0.4.42) + 55078ae. The code is right, the tests prove both directions, and @proagentstore/cli@0.4.42 really is on npm. But the symptom in this ticket still reproduces live right now, and it will keep reproducing until the runner is upgraded — so this stays open.

The measurement that decides it

GET /v1/instances/26f71cd8-…/coding/repos      → cloneStatus: "ready"      ← STILL
ls ~/dev/pas/platform/apps/chess-academy       → total 0                   ← STILL empty
POST …/tools/repo_tree   {}                    → "(no files found at that path)"  success:true   ← STILL
POST …/tools/repo_remote {}                    → "(no git origin remote — …)"     success:true   ← STILL

Why: GET /v1/terminals/nodes → Mac runs runner 0.4.40 and Sergeys-Mac-mini.local runs 0.4.22; npm ls -g @proagentstore/cli → 0.4.40. Both predate /coding/repo-check, so the endpoint 404s, verdictFromCheck reads that as unverified, and cloneStatusForVerdict returns null — the list leaves the stored ready alone. That degradation is correct by design (an old or absent machine must never condemn a repo) and the commit message says so. It is not a defect. It just means two of the four acceptance criteria cannot be true for anyone until they upgrade.

I measured the skew directly, live:

POST /v1/instances/26f71cd8-…/coding/repos  {"localPath":"~/dev/pags-405-verification-no-such-path"}
→ 201 { cloneStatus: "unknown",
        cloneError: "The checkout could not be verified on the connected machine:
                     Runner /coding/repo-check → 404: {\"error\":\"Not found\"}" }

(that row was deleted immediately; the instance is back to its one repo.)

Acceptance, criterion by criterion

• 1. Adding a local path that does not exist, is empty, or is not a git repo does not produce a ready repo. ✅ Verified LIVE, in production, today — the add above returned cloneStatus: "unknown", not ready, even with a runner that cannot answer. coding-repos.ts:163 passes onUnverified: "unknown" at add time and null at list time, which is the right asymmetry. This criterion is fully met.
• 2. repo_tree/repo_remote/repo_git return success:false naming the path and the condition. Code ✅ (repo-local.ts:146-155,183-190,225-232,254-265 — the root is consulted only after an empty answer), unit-tested ✅ (repo-local.test.ts:217-223,241-247,256-262). Not observable in production — measured above, both tools still return the old success. Blocked on the runner upgrade.
• 3. The console shows the repo as unusable, with what to do. Code ✅ — repo-status.ts:64-85 adds unusable to the reconciliation (yields to working/offline, outranks active), and ReposList.tsx:141-151 renders the server's own sentence plus the remedy verbatim: "Point it at the real checkout (⚙ Repo settings) or remove it. The agent cannot read code that isn't there." Wired at CodingTab.tsx:371,712. e2e ✅ in Chromium and WebKit at 320px and 390px. Not observable in production — it keys on cloneStatus === "needs_attention", which no repo can reach while every verdict is unverified.
• 4. An empty subfolder of a real checkout still reports "(no files found at that path)" and stays a success. ✅ Both directions are tested, and neither is safe alone — repo-local.test.ts:217 (empty workdir → success:false, names the path, says EMPTY) and :225 (empty subfolder of a healthy checkout → success:true, byte-for-byte "(no files found at that path)"), with :234 asserting the check is sent {workDir: "~/work/my-repo"} — the root, never the tool's path. Plus :274, the CLI-skew case: an old runner's {error:"Not found"} leaves the old wording untouched.

The runner half — verified against the published artifact, not the source tree

npm view @proagentstore/cli version → 0.4.42, published 2026-08-08T02:20:16Z. The tarball carries /coding/repo-check in dist/browser-runner/server.js and checkWorkdir in dist/browser-runner/coding/repo.js. I ran the published checkWorkdir against the real paths on this machine and chained its output through the deployed verdictFromCheck/cloneStatusForVerdict:

~/dev/pas/platform/apps/chess-academy   → empty           clone_status=needs_attention
  "The configured checkout `…/chess-academy` exists but is EMPTY — nothing was ever cloned into it…"
~/dev/stores/pags/platform              → ok              clone_status=ready
~/dev/stores/pags/platform/workers/api  → ok              clone_status=ready   ← the monorepo trap: a
   subfolder with no .git of its own is insideWorkTree=true, because it is `git rev-parse`, not a `.git` test
~/dev/…/no-such-thing                   → missing         clone_status=needs_attention
/tmp (files, not a checkout)            → not_a_git_repo  clone_status=needs_attention
old runner 404 {error:"Not found"}      → unverified      clone_status=null (leave alone)

So the moment a 0.4.42 runner connects, this ticket's own repo becomes needs_attention with that exact sentence. Every link in the chain is proven; only the version on the machine is missing.

Tests re-run here

pnpm vitest run workers/api/src/lib/coding-workdir.test.ts \
  workers/api/src/lib/connectors/repo-local.test.ts \
  workers/api/src/routes/coding-repos.test.ts \
  packages/browser-runner/src/coding/repo.test.ts \
  agents/coder/web/src/repo-status.test.ts
 ✓ repo-status (28) ✓ coding-workdir (10) ✓ coding-repos (23) ✓ repo-local (25) ✓ repo (7)
 Test Files 5 passed (5) | Tests 93 passed (93)

Playwright, Chromium and WebKit at 320px/390px: the 4 #405 specs pass, including "a healthy repo is untouched: no banner, and it still reads Ready".

To close this, one step

On both machines (Mac, Sergeys-Mac-mini.local):

npm i -g @proagentstore/cli@0.4.42     # currently 0.4.40 / 0.4.22
pags up

then open Chess coder → Coding and confirm apps/chess-academy reads "Path unusable" with the red remedy card instead of "Ready", and that repo_tree returns the diagnosis with success:false. That is the whole outstanding verification.

Two things found while verifying, neither an acceptance failure

1. cloneStatus: "unknown" still renders as "Ready". resolveRepoState only special-cases needs_attention, so an unverified path — which is every local repo on an old runner, and the exact state the add path now writes — shows the green "Ready" row it always did. The DB no longer claims ready; the UI still does. Only RepoSettingsModal.tsx:87 surfaces the raw status, and nothing surfaces the cloneError that explains it. Worth a follow-up: unknown deserves its own muted "Not verified" label carrying cloneError, or the ticket's premise survives in the one place the owner actually looks.
2. Seconding the follow-up already noted here: agent-think.ts renders repo status with a three-way ternary, so needs_attention reaches the model as the bare string rather than the diagnosis. It should carry cloneError.

CI note

CI was red on 6f8ce17 and 55078ae (runs 31234711185, 31234765983). Unrelated to this change: 10 WebKit failures, all /console/preferences horizontal-overflow and the timezone select — the #384 defect, fixed afterwards by 79bf551. CI on current main (782f00c) is green; Deploy API and Deploy Host succeeded on 6f8ce17, and the live add-repo behaviour above proves the API half is deployed.

Leaving open pending the runner upgrade.