Track upstream fix: workspace never updates an existing checkout (fro-bot/agent#1634)

[marcusrbrown]

The workspace never updates a repo it has already cloned. /clone checks whether the destination exists, validates it is a usable worktree, and returns 409 repo-exists. There is no git fetch, pull, checkout, or reset anywhere in that path — verified against apps/workspace-agent/src/clone.ts at the currently pinned v0.113.2.

The gateway treats repo-exists as success and proceeds to run against whatever is on disk.

Why this matters here specifically

/workspace/repos is backed by the persistent Docker volume workspace-repos, so checkouts survive container recreation and redeploys. The workspace container is long-lived. Combined, a repo cloned once can serve every subsequent run for months at the commit it had on the day it was first cloned.

A mention run against a stale tree looks completely normal. The agent reads files, reasons about them, and answers confidently — about code that may be many commits behind main. Nothing in the reply signals which commit it was looking at.

What this is not

Worth separating from something that looks similar. v0.113.2's workspace image bakes OPENCODE_EXPERIMENTAL_DISABLE_FILEWATCHER=true, and the upstream note mentions a cached VCS branch going stale. That cache is read only by GET /vcs and branch-mode GET /vcs/diff, neither of which the mention loop calls, so it is inert in this deployment — see apps/gateway/AGENTS.md.

That is a stale metadata cache. This is a stale working tree. Re-enabling file watching would not fetch anything; the two have nothing to do with each other beyond both being describable as "stale".

The hard part

A naive git pull before each run is wrong, because the tree is not guaranteed clean. A previous run's agent may have left uncommitted edits, and that is legitimate state — the brokered-push flow depends on an agent producing changes in the workspace.

So an update policy has to decide, at minimum:

1. Dirty worktree. Fetch and leave it alone, stash, or refuse to run? Silently discarding an agent's uncommitted work would be worse than the staleness.
2. Detached or non-default branch. A previous run may have switched branches. Does the policy force back to the default branch, or update in place?
3. Timing. Per run, or on a schedule? Per run is fresher and costs a network round-trip on every mention.
4. Failure mode. If a fetch fails — network, auth, rate limit — does the run proceed against the stale tree with a warning, or fail closed? Given the whole point is trusting what the agent read, a silent fall back to stale is the failure mode worth avoiding.
5. Ownership. /clone currently has one job and does it idempotently. Updating is a different operation and probably deserves its own endpoint rather than overloading clone's semantics.

Where it belongs

Almost certainly upstream in fro-bot/agent — clone.ts and the workspace executor live there, and any other deployment reusing a persistent repo volume has the identical exposure. This repo only pins the ref.

Filing it here to record the finding and the analysis. If the shape above is right, it should become an upstream issue with this repo tracking the version that fixes it.

Severity

Not urgent, but not cosmetic either. It degrades silently and in the direction of confident wrong answers, which is the worst way for something to degrade. Came out of the v0.93.1 → v0.113.2 verification pass (#1384).

[fro-bot]

Triage

Summary: /clone in fro-bot/agent's workspace-agent only handles the "doesn't exist yet" case — it clones once, and any later call against an existing checkout short-circuits to 409 repo-exists with no fetch/pull/reset. The gateway treats that 409 as success and runs against whatever is on disk. Because /workspace/repos sits on the persistent workspace-repos Docker volume, a repo cloned once can silently serve every @fro-bot mention for months at the commit it had on day one — and nothing in the response indicates which commit was read.

Reproduction: No code in this repo implements /clone — that lives upstream in fro-bot/agent (apps/workspace-agent/src/clone.ts), so there's nothing to execute here. Instead I checked the claim against this repo's own record of the same finding:

• apps/gateway/AGENTS.md already states, verbatim to this issue's core claim: "If reused checkouts under /workspace/repos drift behind GitHub, that is a checkout-update policy problem — /clone returns 409 repo-exists and never fetches or switches branches — and no amount of file watching fixes it." That line was added by the v0.113.2 verification pass (chore(gateway): pin fro-bot/agent v0.113.2 #1384), which this issue's body says is where the finding originated — consistent, not a fresh claim.
• The only documented mitigation today is fully manual: "To fully clear a cloned repo, delete the volume and let the next mention re-clone it." No automatic or partial update path exists.
• Checked fro-bot/agent issues for prior art: no open issue tracks this. The adjacent one is fro-bot/agent#791 ("/workspace/repos has no persistent volume — every deploy wipes cloned repos"), closed. That fix is what created this exposure — before it, a wiped-on-redeploy volume put a low ceiling on how stale a checkout could get; persisting it removed that ceiling with no update mechanism added in its place.
• fro-bot/agent has "New issue" creation restricted on the repo (confirmed via the issues UI). Filing upstream will need whatever privileged path is normally used for that repo (owner account or an automation credential), not a plain gh issue create from this context.

So: confirmed as a real, already-independently-documented gap, not a new discovery requiring code investigation — the analysis in the issue body holds up.

Next steps:

1. File this upstream in fro-bot/agent, since the fix belongs in clone.ts / the workspace executor and any other deployment reusing a persistent repo volume has the identical exposure. Use whichever privileged path bypasses the repo's issue-creation restriction; reference fro-bot/agent#791 as the change that introduced the exposure window.
2. Track the upstream issue number here (edit this issue's body or add a comment) once filed, per the pattern this repo already uses for upstream-owned findings.
3. No action needed in this repo's code — apps/gateway/upstream.json only pins the ref; there's no local workaround to build without overstepping into upstream's territory (a repo-side pre-run fetch/reset shim would duplicate logic that belongs in clone.ts and risks fighting whatever policy upstream eventually picks for dirty worktrees).
4. Interim operator mitigation (already documented, worth restating explicitly given the severity): for any repo where staleness risk is a concern before an upstream fix ships, an operator can force a fresh checkout by deleting the relevant contents of the workspace-repos volume. This is manual and doesn't scale, but it's the only lever that exists today.
5. When upstream lands a fix, the follow-through here is the same shape as every other upstream bump: pin the new fro-bot/agent ref in apps/gateway/upstream.json, verify per the existing source-contract-verification convention (renovate.json5 ceiling + AGENTS.md note), and confirm the new update policy's behavior (especially the dirty-worktree case) before rolling to production.

Agree with the issue's own severity call: not urgent, but correctly not cosmetic — it degrades silently toward confidently-wrong answers, and the technical-debt label is right pending an upstream tracking link.

---

Run Summary

Field	Value
Event	issues
Repository	marcusrbrown/infra
Run ID	35539242127
Cache	hit
Session	ses_f3f3f913effeIbobB3QSGWyqAP

[marcusrbrown]

Filed upstream as fro-bot/agent#1634, which is where it belongs — /clone lives in apps/workspace-agent/src/clone.ts and this repo only pins a ref, so there is nothing to fix here.

Keeping this open as the tracking issue. It closes when a release carrying the fix lands and apps/gateway/upstream.json moves to it.

The upstream write-up carries the full analysis, including the part that makes this non-trivial: a naive git pull before each run would discard uncommitted agent work that the brokered-push flow depends on, so any update policy has to answer the dirty-worktree and fetch-failure questions before anything else.