Before submitting
Area
apps/desktop
Steps to reproduce
- Open an existing project in the T3 Code desktop app.
- In the composer UI, use the "New worktree" control.
- Leave the base selector set to "From develop".
- Send a prompt so T3 creates a new worktree/thread.
- Push the generated t3code/* branch and open a GitHub PR for it.
- Return to the T3 sidebar and check whether the PR icon appears for that thread.
Additional context:
The worktree was created from the T3 composer UI using the "New worktree" option with "From develop" selected. I did not create the worktree manually with git CLI.
The project does have an auto-run setup script for new worktrees, but it does not switch branches or create worktrees. It only prepares the local development environment after the worktree exists.
Expected behavior
The thread should keep the generated worktree branch, for example t3code/abc12345.
If that branch has an associated GitHub PR, the sidebar should show the PR icon.
Actual behavior
The worktree is created correctly and the actual git branch is t3code/abc12345, but the final projected thread state stores branch=develop.
Because the sidebar matches PRs using thread.branch, T3 looks for a PR for develop instead of the actual worktree branch, so the PR icon is missing.
I inspected the local T3 state DB and saw two thread.meta-updated events emitted almost immediately:
Correct event:
branch=t3code/abc12345
worktreePath=/Users//.t3/worktrees//t3code-abc12345
Then about 10ms later:
branch=develop
worktreePath=/Users//.t3/worktrees//t3code-abc12345
The final projected state keeps branch=develop, even though:
git branch --show-current
t3code/abc12345
And GitHub CLI can find the PR for the actual branch:
gh pr list --head t3code/abc12345 --state all
returns the expected PR
Impact
Minor bug or occasional failure
Version or commit
0.0.24-nightly.20260510.249
Environment
macOS, T3 Code desktop app. GitHub CLI is installed, authenticated, and available in the app server PATH.
Logs or stack traces
Screenshots, recordings, or supporting files
Zrzut ekranu 2026-05-11 o 11.30.37.png
Workaround
Manually correcting the stored thread branch to match the actual git worktree branch makes the PR icon appear.
Before submitting
Area
apps/desktop
Steps to reproduce
Additional context:
The worktree was created from the T3 composer UI using the "New worktree" option with "From develop" selected. I did not create the worktree manually with git CLI.
The project does have an auto-run setup script for new worktrees, but it does not switch branches or create worktrees. It only prepares the local development environment after the worktree exists.
Expected behavior
The thread should keep the generated worktree branch, for example
t3code/abc12345.If that branch has an associated GitHub PR, the sidebar should show the PR icon.
Actual behavior
The worktree is created correctly and the actual git branch is
t3code/abc12345, but the final projected thread state storesbranch=develop.Because the sidebar matches PRs using
thread.branch, T3 looks for a PR fordevelopinstead of the actual worktree branch, so the PR icon is missing.I inspected the local T3 state DB and saw two
thread.meta-updatedevents emitted almost immediately:Correct event:
branch=t3code/abc12345
worktreePath=/Users//.t3/worktrees//t3code-abc12345
Then about 10ms later:
branch=develop
worktreePath=/Users//.t3/worktrees//t3code-abc12345
The final projected state keeps
branch=develop, even though:git branch --show-current
t3code/abc12345
And GitHub CLI can find the PR for the actual branch:
gh pr list --head t3code/abc12345 --state all
returns the expected PR
Impact
Minor bug or occasional failure
Version or commit
0.0.24-nightly.20260510.249
Environment
macOS, T3 Code desktop app. GitHub CLI is installed, authenticated, and available in the app server PATH.
Logs or stack traces
Screenshots, recordings, or supporting files
Zrzut ekranu 2026-05-11 o 11.30.37.png
Workaround
Manually correcting the stored thread branch to match the actual git worktree branch makes the PR icon appear.