[Bug]: With agent browser/device access off, the agent still sees every preview_* and device_* tool#17202

Thanks for the clear report. I traced this through the code on main (a4c9494b). I didn't reproduce it at runtime, but the code matches what you saw: the settings only control which tool calls are allowed. They don't change which tools the agent is offered. The doc comment in settings.ts looks out of date.

What happens

• A credential is always issued. ProviderSessionManager.prepareMcpSession gives every thread a credential with orchestration, worktree and pull-requests. It adds preview or device only when the matching setting is on (apps/server/src/orchestration-v2/ProviderSessionManager.ts:485-491, issued at :523-528). So the t3-code server is attached whatever "Agent browser access" is set to.
• The tool list ignores the credential. /mcp is a single McpServer with every toolkit registered at startup, including layerPreviewToolkit and layerDeviceToolkit (apps/server/src/mcp/McpHttpServer.ts:850-861). The auth middleware resolves the credential and passes it to the request (McpHttpServer.ts:147-180). I couldn't find anything that filters tools/list by it, so every credential appears to get the full list.
• The block happens at call time. The preview handlers call requireThreadMcpCapability("preview") (apps/server/src/mcp/toolkits/preview/handlers.ts:65, :252). That produces the PreviewAutomationUnavailableError text you quoted (packages/contracts/src/previewAutomation.ts:830). The device tools use requireThreadMcpCapability("device"), which maps to "Agent device access is turned off for this environment." (apps/server/src/mcp/toolkits/device/handlers.ts:70-77). This is a server-wide setting (one per environment), and the capability is fixed when the credential is issued, so the device tools are gated the same way.
• This isn't specific to Claude. Claude attaches t3-code whenever a session credential exists and pre-approves mcp__t3-code__* (apps/server/src/orchestration-v2/Adapters/ClaudeAdapterV2.ts:960-988). Codex adds it to mcp_servers without a tool filter (CodexAdapterV2.ts:1336-1347). Pi registers every tool it gets back from tools/list (piT3McpExtensionSource.ts:272-280). So Codex, Pi and the others most likely show the full list too. Only the prompt text is gated: Codex drops the browser and device blocks (apps/server/src/provider/CodexDeveloperInstructions.ts:31-41), and Claude never gets the browser block.

When it diverged

#7083 originally withheld the whole credential, so the t3-code server wasn't attached at all, and the settings.ts comment was written for that version. #10839 (merged Sep 9) started issuing a credential every time, for pull-requests, and turned preview into a capability on it. Its own comment says this "withholds the preview tools without taking the server away". The comment at packages/contracts/src/settings.ts:1299-1310 was never updated. A day later, #10677 added enableAgentDeviceAccess with "the same way" wording (settings.ts:1344-1352). By then the gate was already capability-based, so it looks like the device tools were never hidden from the list. The orchestration and thread tools added since then mean the server now has to stay attached anyway.

Impact

Calls fail cleanly and tell the agent what to do instead, so the calls themselves appear to stay blocked. The cost is 18 tool definitions in every session with the settings off. There's also some mis-steering: Claude's T3 instructions say "When it exposes preview_* tools, prefer those tools" (apps/server/src/provider/T3OrchestrationInstructions.ts:43), and those tools are listed, so it may try them before falling back.

Possible fixes (not yet decided)

1. Filter tools/list (and refuse tools/call) by the credential's capabilities in McpHttpServer. One server-side change would cover every provider and outside MCP clients. I haven't checked whether Effect's McpServer supports filtering the list per request, so this may need a custom list handler or separate toolkit registration.
2. Hide the tools for each provider instead: for example Claude disallowedTools for mcp__t3-code__preview_* / device_*, and Codex's per-server tool filter. This works but has to be repeated for every adapter.
3. Either way, update the two settings.ts doc comments to describe the capability model.

Related

• #7083: the original withhold feature
• #10839: moved to the always-issued credential
• #10677: added the device setting
• #13559: the actionable preview error text you saw
• #16482: Claude prompt text for other providers' tools
• #7870: preview tools dropping out after a restart
• Discussion #6792

I didn't find a duplicate issue or an open PR that fixes this.

Thanks for tracing this. I reproduced the catalog mismatch with Codex 0.161.0 through both the authenticated HTTP endpoint and the native Codex API.

Your first proposed fix is supported by Effect's existing McpSchema.EnabledWhen annotation. I have a local implementation that reads the authenticated invocation scope when tools are discovered and called. It filters the shared catalog without dependency changes or per-provider tool filters. Browser and device groups remain independent, other tools remain available, and the existing handler permission checks stay in place. Calls to hidden tools are refused before reaching their handlers.

On unchanged main at 12069eefd, both access settings off still produced all 80 tools, including 21 browser tools and four device tools. On local commit f6b2b7fc, based on that revision, HTTP discovery and fresh native Codex conversations agreed:

• Neither capability: 55 tools.
• Browser only: 76 tools.
• Device only: 59 tools.
• Both: 80 tools.

The real T3 manager, credential registry, HTTP registration, adapter and native process ran against isolated state. Unrelated domain services were stubbed, and only Codex was tested live. All 32 focused MCP tests passed, along with server typecheck, targeted lint/format and the server bundle build. The test command, from apps/server, was:

I also checked access changes in both directions while attached: the credential and catalog stayed unchanged until idle detach/reopen, which refreshed both while preserving the native conversation and process. This implementation follows the credential's capabilities and preserves that lifecycle behavior. Model-payload token savings remain to be measured.

I'd like to contribute this fix. Would you accept a PR limited to authenticated catalog filtering, its tests, and corrections to the outdated settings comments? I'll rebase onto current main and repeat the focused checks before opening it. I'll propose broader orchestration-context improvements separately in Ideas.

Attempted on current main a50cd989ae using the Linux web dev server and Claude Code 2.1.303. Turned Agent browser access off in Settings → Integrations and confirmed Agent device access was off. Started a new-thread draft; Claude reported authenticated in Providers but was absent from the model picker. The environment then disconnected; reloading still showed “T3 Code on fs-30 did not answer.”

The VM reached load 40 on 4 cores, with provider-probe timeouts and event-loop stalls. The tool-listing step could not be reached, so this attempt neither confirms nor disproves the report. Verification needs a responsive host with a selectable Claude session. Leaving the issue open.

Runtime attempt and selected logs

Browser access disabled

Connection blocked the reproduction

Reproduced on current main 3b95e7831b, Linux web dev server with Claude Code 2.1.303 / Opus 5.5. In Settings → Integrations, both Agent browser access and Agent device access were off. A fresh Claude thread was offered 19 preview tools and four device tools; preview_status and device_list each returned the reported capability denial. Removed needs more info. Runtime transcript.