[MODEL] Sessions change deploy/branch setup without stating the consequence, then each session 'fixes' the symptom the last one caused

Preflight Checklist

• [x] I have searched existing issues for similar behavior reports
• [x] This report does NOT contain sensitive information (API keys, passwords, etc.)

Type of Behavior Issue

Claude reverted/undid previous changes without asking

What You Asked Claude to Do

Across 200+ desktop sessions (17 Sep to 2 Oct 2026) on one private repo, ordinary feature and bug-fix work. Representative asks: "fix the tour button that does nothing" (2 Oct), "why are we having to put a whole entire website up every time" (1 Oct), "why is this such a hold up now? never used to be like this" (30 Sep), "Why has this changed? And can you fix it now, please?" (30 Sep). Fourteen separate times between 17 Sep and 2 Oct I asked what had changed.

What Claude Actually Did

Summary

Solo founder, Claude Max, one private Next.js/Cloudflare repo, 200+ Claude Code desktop sessions in 15 days (17 Sep to 2 Oct 2026). Sessions repeatedly changed infrastructure-level state (deploy trigger, default branch, which branch the working folder was on) and reported it, if at all, as a status line in the closing ledger. Later sessions started from the wrong state, built fixes that were "not live", handed the last step back to me, and when I reported the symptom, answered with a new change that caused the next symptom. One session's wrong statement about a live secret caused a production outage. Support conversation ID 215476207717483 has the full write-up with commit hashes and session IDs.

The chain, concretely

1. 17 Sep: a cloud session created a dedicated deploy branch as the only deploy trigger and left GitHub's default on a stale branch. Every diff/PR comparison in the app then measured against a dead branch for two weeks. Not stated to me in plain terms.
2. 17 to 19 Sep: multiple sessions deployed to the same branch with no coordination. Sessions logged "other sessions' deploys reverted this work 7+ times" and "parallel deploys have reverted each other all week", and carried on.
3. 24 Sep: a session wrote "fix was built on the wrong branch, [that branch] isn't part of the deployed line", then created a new branch from that exact commit (650 commits behind the live branch) and left the main working folder on it. 45 subsequent sessions started there.
4. 17 to 27 Sep: per-push deploys burned all 2,000 free GitHub Actions minutes in ten days; GitHub blocked runs; sessions moved CI onto a self-hosted runner, which then stalled unrelated jobs.
5. 27 Sep: a session told me a live Cloudflare Worker secret was "never wired to anything" (it had been set by a cloud session, invisible to the repo). I revoked it on that word. Production went down.
6. 30 Sep: I asked why deploys were now ten minutes each when they "never used to be". Answer: "ten minutes, by design." It was a regression from step 1.
7. 1 Oct: I asked to stop being handed git commands to run. The session bundled the permission fix I wanted with its own idea, a twice-daily deploy window, plus four unrelated merges, into one NEEDS DECISION. I asked "What's the yes?" and then said yes. It never stated the consequence: a push now waits up to 12 hours. Next morning deploys felt 10x slower and I did not know why.
8. 2 Oct: a new session, asked about an unrelated UI bug, found and fixed all of the above in about an hour. The same hour, the session from step 7 asked me whether to put the deploy window back.

Across 1 Aug to 2 Oct, a transcript scan finds 176 messages from me asking why something had changed or reverted, and 480+ session messages admitting wrong branch, overwritten work, reverted deploys, "not live", rollbacks or outages.

Expected Behavior

When a session changes how the repository deploys, which branch is the default, or which branch the working folder is on, it says so in one plain sentence with the consequence ("a push will now wait up to 12 hours to go live") and asks first, on its own, never bundled with unrelated decisions. When a session finds the working folder on a non-live branch, or finds deploys overwriting each other, it fixes that or stops; it does not write it into the ledger and carry on. Parallel sessions on one repo get a visible warning or a coordination mechanism. A session never tells a user a live secret is unused without checking the deployed surface. "Fixed" means one of three stated things: in the build, deployed, or seen working.

Files Affected

The deploy workflow file (trigger changed 17 Sep, 1 Oct, reverted 2 Oct); the main working folder's checked-out branch (left on a side branch 24 Sep to 2 Oct); GitHub default branch setting (stale until 2 Oct); 114 leftover git worktrees, 78 GB; one Cloudflare Worker secret (revoked on a session's wrong word, 27 Sep, production outage).

Permission Mode

Accept Edits was ON (auto-accepting changes)

Can You Reproduce This?

Sometimes (intermittent)

Steps to Reproduce

Not a single-prompt repro; it is a multi-session pattern. To reproduce the shape of it:

1. One private repo with deploy-on-push to a dedicated branch and a stale default branch.
2. Run several Claude Code desktop sessions on that repo in parallel over a few days, in bypass-permissions mode, mixing local and cloud sessions.
3. Let one session change infra state (deploy trigger, default branch, or check the working folder out onto a feature branch) and finish its turn.
4. Start new sessions in the same folder and ask for ordinary fixes. Observe: sessions build on the wrong branch, report work as "not live" or "cherry-pick to go live", and hand the last step to the user.
5. Report the symptom ("why is this slow / why did this revert") to a fresh session. Observe: it proposes a new change to the symptom, bundled into a NEEDS DECISION with unrelated items, without stating that a previous session caused it or what the consequence is.
6. Ask a session whether a secret set out of band (e.g. via wrangler secret put) is in use. Observe: it answers from the repo, not the deployed surface.

Claude Model

Opus

Relevant Conversation

24 Sep, a session: "fix was built on the wrong branch, [that branch] isn't part of the deployed line at all." It then created the new working branch from that same commit.

25 Sep, a session: "Wrong table, wrong branch, missing table, generic rules instead of yours. Four times, each one confidently."

27 Sep, a session: "committed as [hash] on [a feature branch], not deployed. Cherry-pick onto the deploy branch to go live."

18 Sep, a session: "other sessions' deploys reverted this work 7+ times." 19 Sep: "parallel deploys have reverted each other all week."

30 Sep, me: "We used to just do changes and they would be super quick. Now it's taking like 10 minutes to change one thing. And then 10 minutes for it to deploy. Why is this such a hold up now? Never used to be like this." Session: "Deploy: ten minutes, by design."

1 Oct, session, bundling three decisions: "NEEDS DECISION: yes to the permission rule and to the twice-daily deploy window?" Me: "What's the yes?" Then: "Okay, yes, if it's clean, then do it." Commit landed four minutes later. The consequence (pushes wait up to 12 hours) was never stated.

2 Oct, the session that built the window, an hour after another session reverted it: "NEEDS DECISION: put the twice-daily deploy window back?"

Impact

Critical - Data loss or corrupted project

Claude Code Version

2.1.246 (Claude Code)

Platform

Other

Additional Context

Patterns

• Each "fix" was a reaction to the last fix's symptom, and I was the one reporting the symptoms. No session ever said "a previous session changed this; here is what it was before; do you want it back?"
• Sessions saw the cause and wrote it as a status line at least five times without fixing it (24, 25, 27 Sep; one memory note about pushing by hand "a dozen times" was carried through six sessions).
• The same pattern is on record from August: 1,271 session transcripts 1 Aug to 16 Sep, 162 messages from me asking why something changed or reverted, 417 session messages admitting wrong branch, overwritten work, reverted deploys, not live, rollbacks or outages. Two production outages in August; one on 27 Sep; a Signal assistant outage on 12 Aug from an unlisted spend cap.
• Cloud sessions cannot see local env, deployed secrets or the database; what they set up leaves no trace a later session can read (the 27 Sep outage), and what they cannot finish comes back as "handover" documents. 13 cloud sessions pushed 142 commits in the period, 97 of them on 17 and 18 Sep.
• Bundled NEEDS DECISION prompts: three unrelated yes/no questions in one line led to me asking "What's the yes?" and then approving something whose consequence was never stated.

What the product should do

• State infra changes in one plain sentence with the consequence, and ask first. Never bundle them with other decisions.
• On finding the working folder on a non-live branch, or deploys overwriting each other: fix it or stop.
• Parallel sessions on one repo need a visible warning or a coordination mechanism.
• Never call a live secret unused without checking the deployed surface.
• "Fixed" means in the build, deployed, or seen working, and the session says which.

Full write-up with commit hashes and session IDs is with Anthropic support, conversation 215476207717483.