Before submitting
Area
apps/web (including the desktop app's shared web UI)
Steps to reproduce
-
Create a workspace directory that is not itself a Git repository but contains multiple repositories:
~/work/
repo-a/.git/
repo-b/.git/
-
Add ~/work to T3 Code as one project. This is useful for cross-repository threads that need to work in several child repositories from one parent directory.
-
Start a thread in that project.
-
Put a pull request URL for one of the child repositories in the thread, for example https://github.com/org/repo-a/pull/123.
-
Right-click the rendered PR link.
Expected behavior
The context menu should offer Link to thread, as documented and implemented by #8160. The PR URL already identifies the host, repository, and PR number.
If T3 requires a project association to fetch PR state, it should resolve a matching child repository or let the user select/register the matching repository instead of silently removing the link action.
This workflow previously allowed me to associate a PR with the thread when its URL appeared in the conversation.
Actual behavior
The context menu does not offer Link to thread. A PR can only be linked when its repository already matches a separately registered T3 project in the same environment.
The non-Git parent project has no repositoryIdentity, and T3 does not discover its child repositories for this lookup, so a cross-repository thread cannot be associated with any of their PRs.
Source-level diagnosis
Current main parses the PR URL in ChatMarkdown.resolveThreadPullRequest, then calls findProjectForChangeRequest across registered projects in the thread's environment. If no project matches, it returns null, which makes threadLinkAction undefined and omits Link to thread from the context menu:
The persisted ThreadLinkedPullRequest also requires a projectId, so the current contract cannot represent a URL-linked PR that has no separately registered T3 project.
Impact
Major degradation or frequent failure
Cross-repository threads are the reason to use a non-Git parent workspace. Those threads lose PR status in the sidebar and cannot auto-settle when the PR merges unless every child repository is also registered as a separate T3 project.
Version or commit
Current desktop app; exact installed build unavailable. Confirmed in source on main at fff33f9e851912363c5b1f3ac65598be35eb5f0d.
Environment
macOS, T3 Code desktop/shared web UI, GitHub pull requests, non-Git parent workspace containing multiple child Git repositories.
Logs or stack traces
No relevant logs. The link action is omitted by the client-side project lookup.
Screenshots, recordings, or supporting files
None.
Workaround
Register every child repository as its own T3 project. Once a child has a matching repositoryIdentity, the parent-workspace thread can find that project in the same environment and offer Link to thread.
This is cumbersome for directories containing many repositories and does not preserve the intended single-project, cross-repository workflow.
Related work
Follow-up: linked PR number is missing from the thread list
Registering the child repository as a separate T3 project in the same environment restores the Link to thread action in the non-Git parent thread. The link action completes, confirming that the project lookup described above is the blocker for creating the association.
However, the linked PR number is still not displayed on that thread's row in the thread list/sidebar.
Additional reproduction
- Register the child repository as its own T3 project.
- Return to a thread whose workspace is the non-Git parent directory.
- Right-click the child repository's PR URL and choose Link to thread.
- Inspect the parent thread's row in the thread list.
Expected
The linked PR number and state should appear on the thread row, which is part of the behavior described by #8160. The linked PR should remain visible even though the thread's own project is the non-Git parent and the linked PR's projectId belongs to the registered child project.
Actual
The association can be created, but no linked PR number appears in the thread list. This makes the child-project workaround incomplete: it restores the link command without restoring the sidebar visibility that makes the association useful.
Before submitting
Area
apps/web (including the desktop app's shared web UI)
Steps to reproduce
Create a workspace directory that is not itself a Git repository but contains multiple repositories:
Add
~/workto T3 Code as one project. This is useful for cross-repository threads that need to work in several child repositories from one parent directory.Start a thread in that project.
Put a pull request URL for one of the child repositories in the thread, for example
https://github.com/org/repo-a/pull/123.Right-click the rendered PR link.
Expected behavior
The context menu should offer Link to thread, as documented and implemented by #8160. The PR URL already identifies the host, repository, and PR number.
If T3 requires a project association to fetch PR state, it should resolve a matching child repository or let the user select/register the matching repository instead of silently removing the link action.
This workflow previously allowed me to associate a PR with the thread when its URL appeared in the conversation.
Actual behavior
The context menu does not offer Link to thread. A PR can only be linked when its repository already matches a separately registered T3 project in the same environment.
The non-Git parent project has no
repositoryIdentity, and T3 does not discover its child repositories for this lookup, so a cross-repository thread cannot be associated with any of their PRs.Source-level diagnosis
Current
mainparses the PR URL inChatMarkdown.resolveThreadPullRequest, then callsfindProjectForChangeRequestacross registered projects in the thread's environment. If no project matches, it returnsnull, which makesthreadLinkActionundefined and omits Link to thread from the context menu:ChatMarkdown.tsxChatMarkdown.tsxcontext-menu gatefindProjectForChangeRequestThe persisted
ThreadLinkedPullRequestalso requires aprojectId, so the current contract cannot represent a URL-linked PR that has no separately registered T3 project.Impact
Major degradation or frequent failure
Cross-repository threads are the reason to use a non-Git parent workspace. Those threads lose PR status in the sidebar and cannot auto-settle when the PR merges unless every child repository is also registered as a separate T3 project.
Version or commit
Current desktop app; exact installed build unavailable. Confirmed in source on
mainatfff33f9e851912363c5b1f3ac65598be35eb5f0d.Environment
macOS, T3 Code desktop/shared web UI, GitHub pull requests, non-Git parent workspace containing multiple child Git repositories.
Logs or stack traces
Screenshots, recordings, or supporting files
None.
Workaround
Register every child repository as its own T3 project. Once a child has a matching
repositoryIdentity, the parent-workspace thread can find that project in the same environment and offer Link to thread.This is cumbersome for directories containing many repositories and does not preserve the intended single-project, cross-repository workflow.
Related work
Follow-up: linked PR number is missing from the thread list
Registering the child repository as a separate T3 project in the same environment restores the Link to thread action in the non-Git parent thread. The link action completes, confirming that the project lookup described above is the blocker for creating the association.
However, the linked PR number is still not displayed on that thread's row in the thread list/sidebar.
Additional reproduction
Expected
The linked PR number and state should appear on the thread row, which is part of the behavior described by #8160. The linked PR should remain visible even though the thread's own project is the non-Git parent and the linked PR's
projectIdbelongs to the registered child project.Actual
The association can be created, but no linked PR number appears in the thread list. This makes the child-project workaround incomplete: it restores the link command without restoring the sidebar visibility that makes the association useful.