Repository navigation
Duplicate repo record for ProAgentStore/platform is stuck in cloning, and the session attached to it runs unguarded because the platform sends no repository scope for a record with no GitHub coordinates #760
Description
What is wrong
Two repo records point at the same GitHub repository:
| record | state | workdir |
|---|---|---|
pags/platform |
ready |
~/dev/stores/pags/platform |
ProAgentStore/platform (repo_2b2657fb-31e5-48a4-99f3-147fffde0925) |
cloning |
— |
The second has been stuck in cloning and never resolved GitHub coordinates.
Why it is more than untidy
The guard report shows 1 of 2 tracked sessions guarded. The unguarded one is the session attached to the stuck record: because that record carries no GitHub coordinates, the platform sends no repository scope for it, and the guard has nothing to enforce against.
That is a containment gap, not a cosmetic duplicate. A gh write outside the intended scope is not refused before it runs — on the repository that hosts the coder that repairs this platform. #679 (closed) scoped the engine's git and gh credentials so a wrong-repo write fails rather than being reported afterwards; a record with no coordinates appears to route around that, since there is no scope to apply. #676 covers the same asymmetry from the credential side.
This is also the exact failure mode that produced misfiled PR #675 — work pushed to the wrong repository from an instance registered elsewhere.
Asks
- Fail closed when scope is unavailable. A session whose repo record yields no repository scope should be refused or run with writes disabled, never run unguarded. Absence of scope must not read as absence of restriction.
- Surface unguarded sessions. The guard count (
1 of 2) is currently only visible if you go looking. An unguarded session should be an error condition, not a ratio in a diagnostic. - Reconcile duplicate repo records. Two records for one GitHub repo should be detected at creation. Decide whether to merge or reject, and clear records wedged in
cloningwith no coordinates after a timeout rather than leaving them attachable. - Remove or repair
repo_2b2657fb-31e5-48a4-99f3-147fffde0925specifically;pags/platformis the correct record.
Related: #679, #676, #684 (runner identity resolving to a deploy key over SSH).
Activity
serge-ivo commentedon Aug 29, 2026
Code guard landed — commit 166b43f
What shipped:
workers/api/src/lib/coding-session-open.ts—startSessionOnRunnernow refuses to start a session when all three conditions hold:repo.provider === "github"— agh-using remote!repo.githubRepo— no GitHub coordinates to scope theghguard with!repo.workdir— not a local-path checkout (which is legitimately unscoped)The session returns a clear
startErrorbefore calling the runner.callRunnernever fires, so no guard is installed for an unguardable session and no runner command reaches the machine.Local-path repos (have
workdir, may have nogithub_repo) and non-GitHub remote repos (GitLab, Bitbucket) are exempt — neither usesghwrites to GitHub.Test pinned:
refuses a GitHub repo stuck with no coordinates and no local path — fail-closed (#760)incoding-session-open.test.ts.Data cleanup still required (owner action, not a code change)
Asks #2–#4 from the issue are out of scope for a code change and require operator data surgery:
repo_2b2657fb-31e5-48a4-99f3-147fffde0925: the duplicateProAgentStore/platformrecord stuck incloning. Delete this row fromcoding_repos(and any attachedcoding_sessionsrows). The correct record is thepags/platformone withworkdir: ~/dev/stores/pags/platform.With the code guard landed, the stuck record can no longer produce a running session even if one is attached — any attempt to start it will now return the "no GitHub coordinates" error. But the row itself still exists in D1 and should be cleaned up.