feat(mcp): target thread launches by project#8678

🟠 High mcp/OrchestratorMcpService.ts:1486

Cross-project createThreads returns an orchestration_error after already creating and potentially starting the target thread, leaving an unreported orphan thread. thread.created.record rejects targets whose project differs from the parent, so make the recording path accept cross-project targets or otherwise prevent the launch from committing before recording succeeds.

✅ Resolved in 192e70c07f29260141b44f5d6ae4d76dadae0815

Fixed in baad86f8cc. thread.created.record now carries the explicitly authorized targetProjectId, and the orchestrator verifies it against the durable target-thread projection while retaining the legacy same-project check when the field is omitted. The integration test now exercises the actual MCP service, ThreadLaunchService, and event-sourced orchestrator for a cross-project launch and parent timeline record.

🟠 High src/orchestratorMcp.ts:212

existing_worktree.worktreePath accepts any non-empty path, so a project-scoped thread can launch with cwd set to /etc or another project's checkout. The value is passed unchanged through resolveLaunchWorkspace into ThreadLaunchService, which persists it and uses it for setup scripts; validate that the path belongs to the selected project before accepting the strategy.

Fixed in baad86f8cc. Existing-worktree paths are resolved canonically, detected through the VCS registry, required to be a repository root, and compared by canonical Git common-dir identity with the selected project. The accepted checkout’s actual branch/path are passed to ThreadLaunchService. Real Git tests cover a sibling worktree, symlink canonicalization, another repository, a plain directory, and branch mismatches.

🟠 High orchestration-v2/Orchestrator.ts:4910

A client can submit thread.created.record with an arbitrary targetProjectId and record a cross-project thread in the parent timeline. Because the branch treats the caller-supplied field as authorization, it bypasses the same-project check and copies the target's title, project ID, run ID, provider, and model into the parent thread; authorization must come from a trusted boundary rather than this untrusted command field.

✅ Resolved in 1f905034f7c91d154ad77f5c0fba447ef694f573

Fixed in 1f905034f7. Cross-project authorization is no longer part of the public orchestration command. The MCP path calls a server-owned recordServerCreatedThread method with the authorized target project supplied out-of-band; public dispatch retains the same-project check. The real MCP/ThreadLaunch/Orchestrator test also asserts that an untrusted public cross-project record command is rejected.

mcp/OrchestratorMcpService.targeting.test.ts:29

The same service module is imported twice, and the namespace copy has to be aliased to VcsDriverRegistryModule because the named import took the module's own name — that alias erases the module namespace this repo uses everywhere else for this module. Consider a single import * as VcsDriverRegistry from "../vcs/VcsDriverRegistry.ts"; and referencing VcsDriverRegistry.VcsDriverRegistry, VcsDriverRegistry.layer, and VcsDriverRegistry.VcsDriverHandle at the use sites.

No longer relevant as of 192e70c07f29260141b44f5d6ae4d76dadae0815

VcsDriverRegistry.ts is a service module and every other consumer in apps/server imports it as a namespace (import * as VcsDriverRegistry from "../vcs/VcsDriverRegistry.ts", then VcsDriverRegistry.VcsDriverRegistry / .layer). Consider matching that here, as this PR already does for the other new service imports (ThreadLaunch, ProjectService), and referencing the handle type as VcsDriverRegistry.VcsDriverHandle.

^{Posted via Macroscope — Effect Service Conventions}

Fixed in 1f905034f7. The service and focused tests now use the VcsDriverRegistry module namespace consistently for the service tag, layer, and handle type.

Shared MCP schema type carries description annotation

Low Severity

OrchestratorMcpThreadWorkspaceStrategy is a shared/reusable schema type used in MCP tool input parameters (OrchestratorMcpCreateThreadsInput and OrchestratorMcpThreadStartInput), and it carries a .annotate({ description: ... }). Per project conventions, shared schema types in MCP tool inputs need to be description-free to avoid compiled JSON schema issues with some LLM providers. The description text belongs on the concrete field annotations in OrchestratorMcpCreateThreadRequest.workspaceStrategy and OrchestratorMcpThreadStartInput.workspaceStrategy instead.

^{Triggered by learned rule: MCP tool input schemas: only one description per allOf branch in Effect Schema compositions}

^{Reviewed by Cursor Bugbot for commit 13bd326fdcbe6765fbbdd5a8793fdfcd0dd7901b. Configure here.}

Fixed in f17378fdad. The reusable OrchestratorMcpThreadWorkspaceStrategy is now description-free; the same guidance is attached only to the concrete create_threads and t3_thread_start workspaceStrategy fields. Contracts typecheck passes and the real MCP toolkit integration test passes.

🟠 High mcp/OrchestratorMcpService.ts:950

createThreads can launch on a different branch than the requested one while still reporting the branch validated at line 950. A concurrent git checkout between enforceExpectedBranch and the asynchronous ThreadLaunchService.launch changes the root or existing worktree after validation, but launch receives only the stale observed branch and never rechecks it. Move the branch check into the launch/setup critical section (or otherwise revalidate immediately before setup) so the expected-branch constraint is enforced atomically.

Fixed in 8c7a4106baa159cc39c2be3ae4c68454193e0bbd. Canonical repository/project authorization remains in MCP preflight, while expected-branch enforcement now re-reads symbolic-ref inside the receipt-aware ThreadLaunch boundary immediately before a fresh launch. Accepted retries consult the durable receipt first and return the original launch even if the checkout later changes; a fresh mismatched key rejects before thread creation. The real MCP and direct ThreadLaunch regressions cover both cases. This is the strongest truthful in-process acceptance guarantee: an arbitrary external Git writer is not governed by T3’s service lock and can still change a checkout after acceptance.

🟡 Medium orchestration-v2/ThreadLaunchService.ts:475

git.currentBranch reports repository errors such as an unreadable or corrupt .git/HEAD as null, so this validation returns an expected-branch mismatch claiming the workspace is detached instead of propagating the GitCommandError. Because git symbolic-ref --quiet --short HEAD uses status 1 for a detached HEAD but status 128 for errors, currentBranch should return null only for status 1 and preserve other failures.

Fixed in 0e9b8981986fff1e2557d067e2a94611f7b363dc. GitWorkflowService.currentBranch now maps only symbolic-ref exit code 1 to detached HEAD and propagates every other GitCommandError. Expected-branch validation remains inside receipt-aware launch admission. Tests cover detached HEAD, non-1 failure propagation, accepted retry after branch change, and fresh mismatch rejection.

Swapping resolveRuntimeMode/resolveInteractionMode for the new non-failing resolveLaunch* helpers drops the caller-visible runtime_mode_escalation_denied / interaction_mode_escalation_denied failure codes on create_threads: an ordinary (non-racing) escalation request now surfaces as a generic orchestration_error wrapping the orchestrator ceiling message, even though those codes remain in OrchestratorMcpFailure and in docs/orchestration-v2/orchestrator-mcp-server.md. Consider keeping the eager typed check here — the policyCeiling still covers the concurrent-downgrade race — and dropping the duplicated resolveLaunchRuntimeMode/resolveLaunchInteractionMode helpers.

^{Posted via Macroscope — Effect Service Conventions}

Addressed in 0e9b8981986fff1e2557d067e2a94611f7b363dc without restoring eager checks, because eager mutable-mode validation would reject an already accepted retry after caller or target modes changed. Fresh launches enforce captured and current runtime/interaction ceilings under serialized caller/target locks. Accepted receipts preserve authenticated scope and key ownership but skip mutable mode revalidation. ThreadLaunch policy failures map to runtime_mode_escalation_denied / interaction_mode_escalation_denied, and Deferred tests assert the typed code plus truthful captured/current ceiling messages.

🟠 High mcp/OrchestratorMcpService.ts:1641

createThreads can launch and start a child thread after the scoped parent run has finished or changed provider ownership. The initial check occurs before target, project, and workspace resolution, and ThreadLaunchService.launch does not revalidate that active-run/session condition; recheck it immediately before launching, as the previous withProjectCreationAdmission path did.

Fixed in 4dd8caf935f836ecd4ee8c5fe3eb681619285293. create_threads carries the captured caller run and provider identity on the existing optional policy ceiling. Fresh thread.create and initial message.dispatch revalidate that exact active, rooted, provider-owned run under the existing sorted caller-and-target locks. Accepted receipts still replay before mutable checks, and cross-project authorization is unchanged. Real MCP/V2 stored-event and Deferred tests cover the parent becoming terminal before create (no child) and between create and message dispatch (no child turn).

Stale parent run still creates threads

Medium Severity

create_threads now checks that the caller run is active only at request start, then launches through ThreadLaunchService without the previous admission-time recheck. A parent run that completes during workspace inspect or provisioning still creates the target thread, and recordServerCreatedThread accepts a completed parent run, so the child can land after the MCP turn has already ended.

^{Reviewed by Cursor Bugbot for commit 0e9b8981986fff1e2557d067e2a94611f7b363dc. Configure here.}

Fixed in 4dd8caf935f836ecd4ee8c5fe3eb681619285293. create_threads carries the captured caller run and provider identity on the existing optional policy ceiling. Fresh thread.create and initial message.dispatch revalidate that exact active, rooted, provider-owned run under the existing sorted caller-and-target locks. Accepted receipts still replay before mutable checks, and cross-project authorization is unchanged. Real MCP/V2 stored-event and Deferred tests cover the parent becoming terminal before create (no child) and between create and message dispatch (no child turn).

🟡 Medium mcp/OrchestratorMcpService.ts:958

A retry with the same clientRequestId returns invalid_request instead of replaying the accepted thread when an existing_worktree has been deleted or is otherwise unresolvable. resolveLaunchWorkspace calls inspectLaunchWorkspace before ThreadLaunchService.launch can read the accepted command receipt, so workspace validation fails before idempotent recovery; resolve the receipt before validating the workspace.

Fixed in 661a3b184abb70fd97afd2951af28b8f547a6c41. createThreads now validates the stable create receipt before mutable workspace planning. An accepted durable existing-worktree binding is replayed at its persisted path without filesystem inspection while ThreadLaunch still handles the exact initial-message receipt and unfinished preparation. The gated integration removes the physical checkout while R1 is preparing and proves the same child/R1 returns without rewriting its binding to root.

🟡 Medium mcp/OrchestratorMcpService.ts:973

When no branch is requested, resolveLaunchWorkspace leaves expectedBranch unset, so ThreadLaunchService.launch skips its currentBranch validation and can persist the snapshot from a checkout that has since changed. Thread details and worktree.status then report a branch different from the checkout used by the run. Populate expectedBranch with the observed workspace.branch when no explicit branch was supplied for both root and existing-worktree strategies.

Fixed in 661a3b184abb70fd97afd2951af28b8f547a6c41. Fresh root and existing-worktree launches carry the observed branch, including detached HEAD as null, into ThreadLaunch's receipt-aware acceptance check. Non-Git roots remain unconstrained only when branch is omitted; explicit branches reject. Tests cover a fresh branch race, detached transitions, and accepted retry after the checkout later changes.

🟡 Medium mcp/OrchestratorMcpService.ts:1725

An idempotent createThreads replay can return a thread with the wrong projectId, providerInstanceId, and model: these fields come from the new request even though ThreadLaunchService returns the previously persisted projection. Clients can therefore route follow-up operations to the wrong project or provider. Serialize these values from projection.thread (or reject mismatched replays).

✅ Resolved in 661a3b184abb70fd97afd2951af28b8f547a6c41

Fixed in 661a3b184abb70fd97afd2951af28b8f547a6c41. Accepted retries derive project, provider/model, modes, title, and returned/recorded thread identity from the durable projection, with both pre-launch and post-launch stable thread/project guards. The real MCP/V2 regression inserts a later R2 and proves the retry and parent record still return the exact durable R1.

🟠 High src/orchestrationV2.ts:2014

An authenticated WebSocket client can set thread.create.policyCeiling.callerThreadId to another active thread, causing dispatch to acquire that thread's threadDispatch lock and block its dispatches without authorization. Because policyCeiling is decoded from the public command, derive this server-internal value server-side instead of accepting it here.

Verified against the actual RPC boundary. dispatchCommand requires the environment-wide orchestration operate scope in RpcAuthorization before ws dispatch, and that principal may already dispatch commands to arbitrary thread IDs in the environment. policyCeiling only adds caller lifecycle/mode restrictions; its sorted caller/target locks do not grant additional authority. MCP constructs the ceiling from its authenticated invocation scope. No change.

🟠 High orchestration-v2/Orchestrator.ts:289

A caller capped at "auto" can launch a child in "auto-accept-edits", allowing edits that should still require approval. runtimeModeRank assigns "auto-accept-edits" rank 1 and "auto" rank 2, so the ceiling check incorrectly considers the less restrictive mode valid; assign "auto" the lower rank.

Verified against the V2 adapters: this ordering is intentional. Codex maps auto-accept-edits to workspace-write/on-request with user review, while auto uses the same filesystem boundary with auto_review; Claude likewise maps them to acceptEdits versus auto. Swapping the ranks would let the narrower auto-accept-edits ceiling authorize the more autonomous auto mode. No change.

🟡 Medium mcp/OrchestratorMcpService.ts:220

When the caller thread is archived or deleted after MCP preflight, createThreads reports generic orchestration_error instead of documented parent_not_active. enforcePolicyCeiling wraps the inactive-thread message as a string in OrchestratorDispatchError, so this function only recognizes the typed OrchestratorCallerRunCeilingError and returns null; handle that string-wrapped lifecycle error as parent_not_active too.

Fixed in 8f61ffb24b3b03854cc4f20dda37d7cbb039cc1b without string matching. When the ceiling carries callerRunId and callerProviderInstanceId, an archived/deleted caller now retains the existing typed OrchestratorCallerRunCeilingError, which the MCP boundary maps to parent_not_active. Legacy ceiling-only callers retain the generic cause. A real gated MCP→ThreadLaunch→V2 archive race proves the typed result and no child creation; restoring the old string cause made that assertion fail with orchestration_error.

🟢 Low orchestration-v2/orchestrator-mcp-server.md:289

The documentation incorrectly says provider and model inherit from the caller, so clients targeting another available provider or model through target.providerInstanceId, target.driverKind, or target.model are told the launch will retain the caller's settings. resolveTarget selects the explicitly requested enabled target and only falls back when those fields are omitted; document that resolution behavior instead.

Fixed in 8f61ffb24b3b03854cc4f20dda37d7cbb039cc1b. The docs now state that an explicit target selects provider/model and omitted target fields inherit from the caller; runtime and interaction modes still inherit by default and remain bounded by the caller ceiling.

Partial root replay rechecks workspace

Medium Severity

When a root thread is already accepted but the initial message is still preparing or missing, mayReplayDurableRoot is false and createThreads re-runs resolveLaunchWorkspace. That re-reads the live checkout and can fail the retry if the branch or path changed, even though ThreadLaunchService skips expectedBranch once a create receipt exists. Existing-worktree replays avoid this by using the stored path.

^{Reviewed by Cursor Bugbot for commit 661a3b184abb70fd97afd2951af28b8f547a6c41. Configure here.}

Fixed in 8f61ffb24b3b03854cc4f20dda37d7cbb039cc1b. Accepted durable non-null paths still replay as existing_worktree, and a retry marked new_worktree retains provisioning recovery. Accepted null-path root/omitted retries now reconstruct root directly from the durable branch, leaving ThreadLaunch in charge of message receipts, fresh missing-message ceilings, and preparation reservation. The real setup-gated test removes the root while exact R1 is preparing and proves the same thread/R1/status, one message, null binding, and unchanged branch; the pre-fix planning path fails that replay.

This translation boundary drops the underlying failure entirely: the callback ignores its argument, and OrchestratorMcpFailure has no cause field, so a ThreadManagementError/OrchestratorV2Error from withProjectCreationAdmission becomes an opaque, context-free message. The previous code preserved it via errorMessage(error). Consider keeping the upstream detail, as every other mapError in this module does.

^{Posted via Macroscope — Effect Service Conventions}

Verified against exact head abf52e5ba2eb5644b1fe134e9291b88425d2c18d. No source change: this is an intentionally redacted caller-facing MCP boundary. withProjectCreationAdmission can carry nested ThreadManagement or Orchestrator failures whose messages include internal project, repository, command, or provider details. Appending errorMessage(error) would serialize those details through OrchestratorMcpFailure. The public response keeps the safe operation and thread index; known safe structured failures are mapped separately. The c01 source-cleared head used this exact mapping, and the refresh range-diff is unchanged. Internal diagnostics can retain a cause at a non-wire boundary, but the proposed public message is not safe.