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

[proagentstore]

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

1. 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.
2. 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.
3. 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 cloning with no coordinates after a timeout rather than leaving them attachable.
4. Remove or repair repo_2b2657fb-31e5-48a4-99f3-147fffde0925 specifically; pags/platform is the correct record.

Related: #679, #676, #684 (runner identity resolving to a deploy key over SSH).

[serge-ivo]

Code guard landed — commit 166b43f

What shipped:

workers/api/src/lib/coding-session-open.ts — startSessionOnRunner now refuses to start a session when all three conditions hold:

1. repo.provider === "github" — a gh-using remote
2. !repo.githubRepo — no GitHub coordinates to scope the gh guard with
3. !repo.workdir — not a local-path checkout (which is legitimately unscoped)

The session returns a clear startError before calling the runner. callRunner never fires, so no guard is installed for an unguardable session and no runner command reaches the machine.

Local-path repos (have workdir, may have no github_repo) and non-GitHub remote repos (GitLab, Bitbucket) are exempt — neither uses gh writes to GitHub.

Test pinned: refuses a GitHub repo stuck with no coordinates and no local path — fail-closed (#760) in coding-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:

• Remove or repair repo_2b2657fb-31e5-48a4-99f3-147fffde0925: the duplicate ProAgentStore/platform record stuck in cloning. Delete this row from coding_repos (and any attached coding_sessions rows). The correct record is the pags/platform one with workdir: ~/dev/stores/pags/platform.
• Detect duplicate records at creation time (ask Conversational agent routing: one tool-calling co-pilot (answer-from-context vs delegate-to-Claude) #3): a separate issue/PR, not landed here.
• Surface unguarded session count as an error (ask Fix MCP OAuth sign-in deadlock, add Google option #2): a separate issue/PR.

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.