[Bug]: branch name helper session starts to work on the main task

[menzels]

Before submitting

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

Area

apps/desktop

Steps to reproduce

started app
put prompt "look at gh issue 109 and fix it"
claude opus 5 high

Expected behavior

the branch name generator should not start to work on the issue.

Actual behavior

What happened

t3code spawns a small Haiku 4.5 helper session at thread creation to produce a branch name. and its only prompt was:

You generate concise git branch names. Return a JSON object with key: branch. Rules: … User message: look at gh issue 109 and fix it

Instead of just answering with JSON, it treated the embedded user message as its task — and it had the full tool set plus full-access permissions in my worktree. Its timeline (UTC):

| 20:14:46 | gh issue view 109 |
| 20:14:52–58 | reads calculate-afa.ts and the spec |
| 20:15:04–26 | 5 Edit calls — the ancillaryAdjustment change and the spec rewrite (this is what broke my Edits out from under me) |
| 20:15:27–20:16:18 | devenv up &, then devenv shell pnpm … test — full backend suite, "All 330 tests pass" |
| 20:16:20 | git checkout .devcontainer/devcontainer.json — that's what reverted the symlink noise |
| 20:16:31 | git add … && git commit → bc2aceb |
| 20:16:35 | finally emits StructuredOutput {"branch": "fix afa ancillary costs conversion"} |
| 20:16:36 | t3code's GitVcsDriver.renameBranch uses that name |

The commit at 20:16:31 landed 15 seconds after my first turn ended, which is why it looked like it came from nowhere.

It's systematic, not a one-off

Every thread on this issue got the same treatment — the branch-namer did the work in each worktree:

• t3code-a952502c (mine): b3291028, 8 edits, committed bc2aceb
• t3code-ab2636ef: 41f5229d, 11 edits, committed 7c4940b at 22:13
• t3code-4e6baf23: da90157e, 8 edits, committed

The sibling title generator ("Generate a title that will help the user recognize this T3 Code thread") behaves correctly in all three — 0 edits. So it's specifically the branch-name prompt: it interpolates the raw user message without isolating it as data, and the session runs with tools and --permission-mode bypassPermissions in the thread's worktree rather than tool-less with a forced structured output.

Worth reporting against t3code 0.0.32. Ruled out along the way: no hooks anywhere (project has no .claude/settings.json; ~/.claude/settings.json is {}), and no cross-worktree writes between the three sessions.

Impact

Major degradation or frequent failure

Version or commit

No response

Environment

linux desktop claude

Logs or stack traces

Screenshots, recordings, or supporting files

No response

Workaround

No response

[t3dotgg]

Thanks for the detailed report. This looks like the same issue tracked in issue #5447.

This is the branch-name form of the same unrestricted Claude metadata helper in issue #5447. The report's title helpers happened to return JSON correctly, while its branch helpers edited, tested and committed the quoted task. That difference does not imply a separate implementation: main routes both operations through runClaudeJson with identical unrestricted tool permissions.

I'm closing this as a duplicate as part of an automated pass on all open issues. I linked this report from issue #5447 so its extra details remain available. This does not mean the underlying bug is fixed.