Cloud agents: file-read tool serves stale default-branch content in the first seconds of a session (terminal/git are correct)

Where does the bug appear (feature/product)?

Cloud Agent (GitHub, Slack, Web, Linear)

Describe the Bug

In roughly the first 5–15 seconds of a cloud agent session, the agent’s read-file tool returns content from a stale snapshot of the default branch instead of the workspace the session was launched on. It returns real, well-formed content from the wrong state — no error, no warning. Terminal commands in the same session (git rev-parse HEAD, cat) were correct at every observation we made, including within seconds of a wrong read. After the first seconds, reads converge to the real workspace and stay correct.

Reproduced 5 times (4 dedicated probe sessions plus the production incident below). The clearest single observation, in one session launched on a branch whose README.md starts with a probe line that does not exist on main:

  • Action 1 — read-file README.md → returned main’s version (no probe line)
  • Action 2 — read-file probe-marker.md (exists only on the branch) → Error: File not found
  • Action 3 (~seconds later) — terminal date -u; git rev-parse HEAD; head -1 README.md; cat probe-marker.md → correct branch head b0bad91b…, README with the probe line, marker file present
  • Actions 4–5 — the same read-file calls now return the branch content

In another run the timing was bounded tighter: the first read failed at session start, and a terminal git rev-parse HEAD a few seconds later already printed the exact head pushed 90 seconds before launch.

How this bit us in production: we run a 4-reviewer PR-review automation. All four fired on the same PR push within a 9-second window, on the same head. Two of them read the current version of their instruction file (.cursor/automations/reviewer.md); the other two read the previous version — the default branch’s state from before a push made 38 minutes earlier — because their first-seconds reads served the stale snapshot. Same trigger, same commit, different instructions, no error anywhere. This “prompt drift” was extremely hard to diagnose because every later check (git, terminal, re-reads) showed the correct content.

We could not determine from outside which layer is behind: either (a) the VM boots on a snapshot of the default branch and the agent starts executing before the workspace is switched to the target ref, or (b) the disk is ready but the read tool’s first calls are answered from a snapshot-side store before it attaches to the live workspace. Both fit all observations; only you can see which.

Steps to Reproduce

  1. In any repo, create a branch where README.md line 1 differs from main (add a marker comment), plus a new file probe-marker.md that does not exist on main. Push.

  2. Launch a cloud agent on that branch with this prompt:

    You are a filesystem probe. Never fetch, pull, or check out anything. Perform in exact order, as fast as possible:
    1. read-file tool: README.md — note its FIRST line
    2. read-file tool: probe-marker.md — note full content
    3. terminal: date -u; git rev-parse HEAD; head -1 README.md; cat probe-marker.md
    4. read-file tool: README.md — note its FIRST line
    Final message: report results 1–4 verbatim in order, including errors exactly as returned.
    
  3. Compare result 1/2 against result 3. In our runs, step 1 returns main’s README and step 2 returns “File not found”, while step 3 shows the branch head and both files on disk.

Note: the window is only the first seconds. If the agent’s first action is a terminal command instead of a read, the window is usually already closed — put the reads first.

Expected Behavior

Every file read reflects the workspace/ref the session was launched on, from the very first tool call — or the agent does not start until the workspace is fully prepared. At minimum, reads and the disk should never disagree without an error.

Operating System

MacOS

Version Information

Cursor 3.14.7 (Universal)
Cloud agents / automations as of 2026-08-05 (probe runs 03:40–04:01 UTC).

For AI issues: which model did you use?

Reproduced independently of model (probe: Grok 4.5; production incident involved four different models in parallel automations).

For AI issues: add Request ID with privacy disabled

Full probe outputs available; agent session links:

  • bc-019fd002-7fc5-72dc-8684-b9579048aa35
  • bc-019fd00f-3402-7d56-9fb7-897f73574f13
  • bc-019fd012-231a-7b0a-a06e-857c0e15803e
  • bc-019fd014-acee-755f-9150-78b62a6ffba6

Additional Information

Timeline of the clearest probe (all UTC, 2026-08-05): push of branch head b0bad91b at 03:57:11 → agent launched on the branch ~03:58 → first read served main’s README → terminal at 03:58:09 showed b0bad91b and correct files → all subsequent reads correct. In all five reproductions git/terminal were correct at every observation; only first-seconds read-tool calls were ever wrong.

Does this stop you from using Cursor

No - Cursor works, but with this issue

Hey @hfjallemark,

We’re still narrowing this on our side. A few details would help us match your setup more closely:

  1. Environment / Builds - For this repo, do you use a configured Cloud Agent environment (with Builds), or do agents start from a fresh machine each time? If you use an environment, what’s the default branch it’s built from?
  2. Where it shows up - Is the stale Read only on the Automations PR-review runs, or also when you start a one-off cloud agent on the same feature branch from cursor.com/agents / the IDE?
  3. Quick check - On a fresh feature-branch session, if the agent’s first action is Shell (git rev-parse --abbrev-ref HEAD && cat <the-file>), and then Read on the same path, does Read still look default-branch stale, or does it match the branch?

If you can grab one more occurrence, a new agent ID (the bc-… from the run URL) right after it happens would help too.

In the meantime, having the agent Shell/git the file before any Read is a reasonable workaround for those review automations.

  1. Yes, the repo uses a configured Cloud Agent environment with Builds enabled, built from the default branch (main). Update stale builds is on with the staleness threshold set to 0.
  2. Both. It happened in the Automations PR-review runs (two of four drivers in the same round read a pre-push version of their instruction file), and in one-off cloud agents we launched ourselves on a feature branch (the probe sessions in the report).
  3. We ran both orderings today on branch probe2/read-vs-disk (its README.md differs from the default branch’s by a marker first line and byte size; head 3a23078a, pushed 12:18:55 UTC today):
    1. Shell first, then Read — agent bc-3270025e-3e26-43ba-af1e-3c7d0bb9f278, launched ~30s after the push. First action was git rev-parse --abbrev-ref HEAD && head -1 README.md in the terminal: correct branch head, correct branch README. Both subsequent Reads returned branch content. No staleness.
    2. Read first (control) — agent bc-610eb93d-8973-4a7f-a034-abdce10f6066, launched several minutes later with no push in between. First action was Read on README.md: it returned the default-branch copy (first line without the probe marker). The terminal immediately after showed the correct branch head and the marker line, and a second Read then returned branch content.

So with one run each: Read-before-Shell was stale, Shell-before-Read was not — consistent with your workaround suggestion, though we can’t distinguish whether the Shell itself clears it or the extra seconds do. Note the control run reproduced the bug even though it was not launched right after a push.