Before submitting
Area
apps/web
Steps to reproduce
Summary
When defaultThreadEnvMode is set to "worktree" in ~/.t3/userdata/settings.json, only the first thread in a project gets its own worktree. All subsequent new threads reuse the same worktree directory — no new branches or worktrees are created.
Analysis
Based on the source code, the flow should be:
✅ Sidebar reads defaultThreadEnvMode from settings → passes envMode: "worktree" to handleNewThread()
✅ Draft thread stores envMode: "worktree" in composerDraftStore
❌ On first message send, client should detect envMode: "worktree" + no worktreePath → build bootstrap.prepareWorktree in the thread.turn.start command — this does not appear to happen for threads after the first
✅ Server-side GitCore.createWorktree() exists and works (PR #1518)
The bootstrap construction in step 3 appears to be the gap — the prepareWorktree payload is never sent for new threads, so the server never creates additional worktrees.
Expected behavior
Each new thread should create an isolated git worktree with its own branch (e.g., t3code/), so that parallel threads don't step on each other's file changes.
Actual behavior
Provider logs (~/.t3/userdata/logs/provider/*.log):
Every thread's claude/system/init event shows the identical cwd.
Confirmed across multiple thread IDs.
No worktree creation events in logs:
Searching server.log and server-child.log for createWorktree, prepareWorktree, or worktree add returns zero results (beyond the startup config showing worktreesDir).
Settings
// ~/.t3/userdata/settings.json
{
"defaultThreadEnvMode": "worktree",
"textGenerationModelSelection": {
"provider": "claudeAgent",
"model": "claude-opus-4-6"
}
}
Impact
Major degradation or frequent failure
Version or commit
No response
Environment
T3 Code version: Alpha (desktop, macOS) Claude Code version: 2.1.79 Provider: claudeAgent (Claude Opus 4.6) OS: macOS
Logs or stack traces
Screenshots, recordings, or supporting files
No response
Workaround
Only workaround for now is manually create worktrees for parallel work:
git worktree add ~/.t3/worktrees/my-project/my-feature -b my-feature-branch main
But that defeats the purpose of the automated flow.
Before submitting
Area
apps/web
Steps to reproduce
Summary
When defaultThreadEnvMode is set to "worktree" in ~/.t3/userdata/settings.json, only the first thread in a project gets its own worktree. All subsequent new threads reuse the same worktree directory — no new branches or worktrees are created.
Analysis
Based on the source code, the flow should be:
✅ Sidebar reads defaultThreadEnvMode from settings → passes envMode: "worktree" to handleNewThread()
✅ Draft thread stores envMode: "worktree" in composerDraftStore
❌ On first message send, client should detect envMode: "worktree" + no worktreePath → build bootstrap.prepareWorktree in the thread.turn.start command — this does not appear to happen for threads after the first
✅ Server-side GitCore.createWorktree() exists and works (PR #1518)
The bootstrap construction in step 3 appears to be the gap — the prepareWorktree payload is never sent for new threads, so the server never creates additional worktrees.
Expected behavior
Each new thread should create an isolated git worktree with its own branch (e.g., t3code/), so that parallel threads don't step on each other's file changes.
Actual behavior
Provider logs (~/.t3/userdata/logs/provider/*.log):
Every thread's claude/system/init event shows the identical cwd.
Confirmed across multiple thread IDs.
No worktree creation events in logs:
Searching server.log and server-child.log for createWorktree, prepareWorktree, or worktree add returns zero results (beyond the startup config showing worktreesDir).
Settings
// ~/.t3/userdata/settings.json
{
"defaultThreadEnvMode": "worktree",
"textGenerationModelSelection": {
"provider": "claudeAgent",
"model": "claude-opus-4-6"
}
}
Impact
Major degradation or frequent failure
Version or commit
No response
Environment
T3 Code version: Alpha (desktop, macOS) Claude Code version: 2.1.79 Provider: claudeAgent (Claude Opus 4.6) OS: macOS
Logs or stack traces
Screenshots, recordings, or supporting files
No response
Workaround
Only workaround for now is manually create worktrees for parallel work:
But that defeats the purpose of the automated flow.