Web agents sometimes use stale main as a base for work
Steps to Reproduce
Start first web agent. Let it create pr and merge.
Start second web agent. It uses main from first agent run( stale at this point ) as base for the changes.
Here’s explanation from agent itself on a timeline
Yes. #450 was already on GitHub main when this thread started. The conflicts were from a stale local checkout, not from #450 landing later.
Timeline (UTC, Sep 3):
22:12 — #450 merges
22:49 — this thread starts
22:54 — first commit on this branch, parented on #449
At start, local main still pointed at #449 (5b893271, 20:30 UTC) and reported “up to date with origin/main.” That origin/main was the snapshot baked into this VM, not a fresh fetch. I did not git fetch origin main before branching.
Hey, thanks for the detailed timeline. It really helps.
This is expected behavior with how Cloud Agent environments work right now. When Builds are enabled for an environment, a new agent starts from a pre-built snapshot that includes a repo checkout from when that snapshot was built. Snapshots rebuild about once an hour, and by default the agent only pulls fresh code on startup if the snapshot is older than 24 hours. A PR merged between the last rebuild and the agent starting won’t be in that checkout, which is what happened with #450.
You can change this at the environment level so agents always fetch the latest code first:
After that, every new agent will fetch the latest default branch before it starts working. This adds a couple seconds to startup. If you want to keep fast startup, you can instead tell the agent in the request “fetch the latest main before making changes”. The agent is told the checkout may be behind, but it won’t always fetch on its own.
Let me know if agents still branch off an old commit after you change the threshold.