Part 16/16 of the shared-core and MCP stack. Based on #10565.
Expose GitWorkflowService.listRefs for the calling thread workspace. Existing worktree handoff and status tools stay unchanged.
This discovers branch-backed refs/worktrees only. Detached unbound inventory and switching an existing checkout require a shared service operation and are intentionally not rebuilt inside MCP. The old workspace work is retained for that extraction.
MCP-only rebuild of #8685, #8680, preserving attribution to Julius Marminge's original work. Original branches remain available for separate service follow-ups.
Validation: The composed stack passes 94 tests across 12 focused files, including shared core MCP and real MCP/V2 integration, attachment intake, project RPC/service contracts, and client model command selection. Server/contracts/shared/client-runtime typechecks and targeted format/lint/diff checks pass. New behavior coverage lives with the shared operation; no per-tool mock suite was added. Current-head CI is shown below.
Layer size: 5 files, +65/-1. No domain-service production implementation or documentation files change in this MCP layer.
Prepared with Codex in the OpenAI agent runtime.
Note
t3_worktree_list MCP tool for branch-backed workspace discoveryt3_worktree_list tool to the worktree toolkit that lists git refs using the caller's worktree path or the project workspace root.CLAUDE_READ_ONLY_T3_MCP_ALLOWED_TOOLS and the T3_MCP_TOOLS presentation registry (label "List workspace branches"), and updates the Claude readonly allowlist test to cover the new tool.Macroscope summarized 1dce00c.
Verdict: Not approved
Macroscope's review found this PR not approvable — This PR adds a new MCP tool for discovering workspace branches and checkout paths, including wiring it into the default Claude read-only tool policy. The behavior is read-only and scoped, but the new capability and policy default change warrant human review.
No code changes detected at 1dce00c. Prior analysis still applies.
You can add or adjust custom eligibility rules. Learn more.
⚠️ The latest CI run did not produce a thread transfer result for 1dce00c.
This comment will update automatically after the next completed run.
Bugbot uses usage-based billing for this team and has hit its on-demand spend limit.
A team admin can raise the spend limit in the Cursor dashboard, or wait for the next billing cycle to continue.
| … | … | @@ -1,10 +1,36 @@ | |
| 30 | + | return yield* git | |
| 31 | + | .listRefs({ ...input, cwd: caller.worktreePath ?? project.value.workspaceRoot }) | |
| 32 | + | .pipe(Effect.mapError(unavailable)); | |
| 33 | + | }), | |
This handler adds new backend behavior (capability gate, project lookup, worktree-vs-workspace cwd selection, GitWorkflowService.listRefs delegation) but nothing exercises it — the only test touched by this PR is the Claude adapter's tool-name list, and t3_worktree_list is not covered by WorktreeMcpService.test.ts either.
Consider adding a focused test that calls the tool through the toolkit with test layers for the external services only, following the pattern in apps/server/src/mcp/toolkits/core.test.ts (Layer.mock(ProjectService) / Layer.mock(GitWorkflowService) / Layer.mock(ThreadManagementService) plus Effect.provideService(McpInvocationContext, scope)), asserting at least: capability_denied without the worktree capability, invalid_request when the project is absent, and that cwd resolves to caller.worktreePath when set and to project.workspaceRoot otherwise.
Posted via Macroscope — Effect Service Conventions
The maintainer asked for thin wrappers with shared MCP tests rather than a per-tool forwarding suite. This handler retains the credential capability check, resolves the existing project record, selects the existing worktree path or project workspaceRoot, then calls GitWorkflowService.listRefs unchanged. Shared object-schema/registration/scope/error tests and the annotation-derived allowlist check cover the MCP boundary; Git behavior remains in the existing service tests. No detached inventory, path-identity resolver, Git mutation or checkout state machine is added here. No concrete incorrect behavior was identified in this comment.
| … | … | @@ -1,10 +1,36 @@ | |
| 30 | + | return yield* git | |
| 31 | + | .listRefs({ ...input, cwd: caller.worktreePath ?? project.value.workspaceRoot }) | |
| 32 | + | .pipe(Effect.mapError(unavailable)); | |
| 33 | + | }), | |
This handler carries real backend behavior (capability gate, project lookup / not-found path, and the caller.worktreePath ?? project.workspaceRoot cwd choice) but no focused test covers it. The sibling worktree tools keep this logic in WorktreeMcpService, which is tested in WorktreeMcpService.test.ts with Layer.mock test layers for ThreadManagementService / ProjectService / GitWorkflowService.
Consider either moving the resolution logic into WorktreeMcpService (e.g. a listRefs(scope, input) operation) and covering it in that existing harness, or adding a focused handler test that provides test layers for ProjectService and GitWorkflowService and asserts the capability denial, project-not-found, and worktree-vs-workspace-root cwd cases.
Posted via Macroscope — Effect Service Conventions
This repeats the earlier per-tool test request. The maintainer asked to avoid moving wrapper plumbing into new service methods or duplicating service tests just to expose a tool. The existing branch-backed listRefs operation is reused, with caller capability/project lookup and worktreePath-or-workspaceRoot forwarding. Shared MCP schemas/scope/errors and the readonly allowlist are tested; existing GitWorkflowService tests own the Git behavior. No concrete incorrect branch/path behavior is identified here, and no new WorktreeMcpService API is being added.
The handler-specific capability, project-not-found, and cwd-selection behavior remains untested: t3_worktree_list resolves these directly in handlers.ts and does not use WorktreeMcpService; existing listRefs mocks only cover handoff. Shared schema/service coverage does not exercise that wrapper path.
Bugbot uses usage-based billing for this team and has hit its on-demand spend limit.
A team admin can raise the spend limit in the Cursor dashboard, or wait for the next billing cycle to continue.
Bugbot uses usage-based billing for this team and has hit its on-demand spend limit.
A team admin can raise the spend limit in the Cursor dashboard, or wait for the next billing cycle to continue.
Added 1 commit
