[Bug]: Generating MR text leaks data from other threads

[razzeee]

Before submitting

• I searched existing issues and did not find a duplicate.
• I included enough detail to reproduce or investigate the problem.

Area

Not sure

Steps to reproduce

1. Create a change
2. Have multiple things in the works e.g. in worktrees
3. Hit commit & push & MR (to gitlab)

Expected behavior

The generated MR message should only be aware of context in that windows history and don't include infos from other changes.

Actual behavior

We end up with bits and pieces of work done in other threads.

Impact

Doesn't block - but is annoying

Version or commit

0.0.40

Environment

Fedora Linux

Logs or stack traces

Screenshots, recordings, or supporting files

No response

Workaround

No response

[juliusmarminge]

Thanks for the report — this looks real.

What we see in the code

Commit & push & MR (GitLab included) generates the title/body in GitManager.runPrStep from git range context (base..HEAD commits + diff) plus the source-control writing style. It does not use this window/thread’s chat history. threadId is only used afterward to link the created MR.

Two ways other threads can leak in, especially with several worktrees:

1. Default “Repository conventions” style injects the last ~20 commit subjects from HEAD (including ancestor commits on shared history) into the generator prompt, along with AGENTS.md / CLAUDE.md.
2. Most text-generation writers still start in the live checkout. Claude already isolates thread titles in a temp directory so project files don’t bleed in; Antigravity isolates all helper runs. Codex, Claude (commit/MR), Grok, OpenCode, and Cursor still run in the repo. Worktrees share a git object store, so a read-only helper can still see other branches.

That matches “bits and pieces of work done in other threads” even when the Git action cwd is the current worktree.

Not a duplicate. Closest open work is #9914 (isolate Cursor metadata generation from the project directory) — same class of bug, Cursor-only so far.

Next: treat this as an isolation bug. MR text should only see this action’s commits/diff (and this thread, if we later add transcript context), not sibling worktrees or repo-wide recent subjects. Extending the temp-workspace pattern from Claude titles / Antigravity / #9914 to generatePrContent for every writer is the likely fix.

If you have one handy: a redacted leaked MR vs the intended change, plus which source-control writer model you use (Settings → Source Control), would help confirm which path fired. Not required to keep this open.