[saphid]

Problem

Users can turn a provider on or off for one project (Settings → Providers, project scope). delegate_task enforces that: it refuses a provider that is off for the caller's project. But orchestrator_capabilities only looked at the machine-wide provider snapshots, which include every instance that any project turns on.

So an agent working in a project that turned a provider off, or that never turned on a provider another project uses, is told that provider has canRunChildTask: true with no constraints. It picks that provider, and delegate_task then refuses with "disabled for this project". The agent wastes a turn and may give up on delegating.

Change

When the call comes from a thread, capabilities now checks each provider with resolveProjectProviderInstanceEnabled for that thread's project. This is the same check delegate_task uses (through ThreadManagementService.assertProviderInstanceEnabled), and the same one the web composer applies in applyProviderInstanceSettings. A provider that is off for the project is reported with the existing Provider instance is disabled. constraint. A snapshot that is already disabled is never turned on, because disabled snapshots carry placeholder health and auth data. Callers without a thread get the same answer as before.

Scope and approval

Very small, focused fix for an obvious bug, so no prior issue: one consumer of the per-project provider setting (#17879) ignored it, while the operation it describes (delegate_task) honors it. The change is 10 lines in one function and reuses the existing resolver and constraint text, so no model-facing descriptions change.

Overlap search: the local PR index and GitHub search for orchestrator_capabilities, project, disabled, and provider turned up nothing that touches this function. The closest PRs are #26979 (adds projectId to the text-generation usage fallback, a different consumer) and #28133 (delegate_task inherited options).

Verification

• Red on main: I extended the existing advertises orchestration capability from registered adapters rather than a driver allowlist case with an instance that is on machine-wide but off for the caller's project. It fails with AssertionError: expected true to be false on projectDisabled.canRunChildTask.
• Green: vp test run src/mcp/OrchestratorMcpService.test.ts passes 57/57. OrchestratorMcpToolkit.integration.test.ts, AcpMcpStdioBridge.test.ts and AcpRegistryAdapterV2.test.ts pass 41/41.
• vp run check:changed: format, lint, knip, typecheck (3 packages) and tests all pass.
• The test now sets up the existing pi, acpRegistry and antigravity instances as enabled. The resolver, like delegate_task, treats unconfigured non-default instances as off.
• Not checked: a live MCP call against a running server.

Reviewed with sol-loop: 1 round with GPT-6.1 Sol on high. Sol verdict: approved.

Created with Claude Opus 5.5 in Claude Code (T3 Code).

🤖 Generated with Claude Code

[macroscopeapp]

Approvability

Verdict: Approved at e08dee6

Macroscope's review found this PR approvable — Capability reporting now marks providers disabled for the caller's project as unavailable for child tasks, matching existing delegation restrictions. The change leaves settings, product defaults, and execution enforcement unchanged.

^{You can add or adjust custom eligibility rules. Learn more.}

[coderabbitai]

No actionable comments were generated in the recent review.

Walkthrough

Provider capability evaluation now checks project-specific enablement when a parent thread exists. A test covers a Codex provider that is enabled in server settings but disabled by a project override.

Changes: Provider capability evaluation

Layer / File(s)	Summary
Project-aware capability evaluation apps/server/src/mcp/OrchestratorMcpService.ts, apps/server/src/mcp/OrchestratorMcpService.test.ts	Capability constraints use project-specific enablement when a parent thread exists. Without a parent, they use the provider’s existing enabled state. The test verifies that a provider disabled for the project remains listed but cannot run child tasks and reports the disabled-provider constraint.

Estimated code review effort: 2 (Simple) | ~10 minutes

Change: Bug fix

Suggested reviewers: juliusmarminge

Merge Risk: Minimal · up to e08de

Project-disabled providers are reported as unavailable. No merge-blocking issue was identified.

Pre-merge checks: 4

Check name	Status	Explanation
Title check		The title clearly and concisely describes the main fix: preventing orchestrator capabilities from offering providers disabled for the project.
Description check		The description includes complete Problem, Change, Scope and approval, and Verification sections. It explains the behavior, implementation, scope rationale, test results, and the remaining unverified …
Linked Issues check		Check skipped because no linked issues were found for this pull request.
Out of Scope Changes check		Check skipped because no linked issues were found for this pull request.

Full details: Description check

Explanation

The description includes complete Problem, Change, Scope and approval, and Verification sections. It explains the behavior, implementation, scope rationale, test results, and the remaining unverified live MCP scenario.

Finishing Touches

Generate unit tests (beta)

• Create a new PR

• Autofix · Keep fixing CodeRabbit findings and required CI, and resolving merge conflicts

Warning

Some tools did not complete. Review the errors below.

ast-grep (0.51.1)

ast-grep could not parse rule config: /ast-grep-rules/ast-grep-essentials/rules/php/security/ssti-dynamic-template-string-php.yml

Usage-based review receipt

• Mode: Continue automatically
• Reviewed files: 2
• Charged: $0.50
• View usage details

Note

This review was completed with usage-based billing: files reviewed beyond your plan's included limits are billed at $0.25/file. View usage-based billing.

CodeRabbit Verify

• Run CodeRabbit Verify to test the changes in this pull request.

Recent review info

Run configuration

• Source mode: Auto
• Repository: pingdotgg/t3code
• Branch: main
• File: .coderabbit.config.ts
• Commit: 07846fc
• Layers: Repository TS config
• Review profile: CHILL
• Plan: Advanced
• Run ID: 769e7343-1ebc-423f-9e5d-223cf6c3e51e

Commits

Reviewing files that changed from the base of the PR and between 07846fc and e08dee6.

Files selected for processing: 2

• apps/server/src/mcp/OrchestratorMcpService.test.ts
• apps/server/src/mcp/OrchestratorMcpService.ts

Limit details: You’ve used all 10 included reviews currently available.

[maria-rcks]

Note

Written by gpt-6.1-sol on behalf of Maria

Verified in a real dev environment

verified as-is at e08dee635afd8a565c13187590643ef8e34606af on this linux vm. used repo Playwright with /usr/bin/google-chrome, real background dev servers, and real Codex gpt-6.1-sol turns through the local proxy. created the project, provider instance, project override, and conversation through the app. no mocks or seeded demo data.

• reproduced on github/main (61c3794c32): a globally enabled Codex instance disabled for this project was advertised with canRunChildTask: true and no constraints. an actual delegate_task call rejected it as disabled for the project.
• ran the exact pr head with the same app-created state after stopping main. fresh orchestrator_capabilities returned canRunChildTask: false, canRunCrossProviderChildTask: false, and Provider instance is disabled. for that instance. delegation still rejected it.
• neighboring behavior: the enabled Codex instance completed a real delegated child with ENABLED_PROVIDER_OK. re-enabling the project override restored capability availability, and a child on that instance completed with REENABLED_PROVIDER_OK.
• checked the persisted MCP inputs/results against the rendered conversation. 69 existing tests passed across OrchestratorMcpService.test.ts, OrchestratorMcpToolkit.integration.test.ts, and AcpMcpStdioBridge.test.ts through blacksmith-check. no source changes were needed.

short runtime transcript

Not verified

native desktop, iOS/Android, remote relay/tunnel connections, non-Codex provider execution, and MCP callers without a parent thread were not exercised. this pass used the linux web client and Codex provider path. no merge, rebase, force-push, label changes, or code pushes.