[BUG] All local MCP server tools blocked by PreToolUse:Callback in Code mode

I've seen similar permission blocking issues when the MCP server name doesn't match what's expected in the permission config. double check that the server name in your settings.json allowedTools list matches exactly what the MCP server reports as its name during initialization. even a trailing space can cause the callback to deny everything.

our MCP server where we handle tool registration and naming: https://github.com/mediar-ai/mcp-server-macos-use/blob/main/Sources/MCPServer/main.swift - the tool names need to match exactly between server registration and the permission config.

Can confirm this bug suddenly appearing today with Cowork and Code on macOS. Every local MCP is blocked, despite them working perfectly fine in Claude Chat/Projects.

All locally configured MCP servers are non-functional in Cowork mode. Every tool call is intercepted and blocked. This happens regardless of which MCP server or tool is called. The block is at the PreToolUse:Callback layer, not the MCP server or permission level.

I've tested with all tools set to "Always allow" in the connector permissions — makes no difference. Every call is blocked before reaching the MCP server. The error message misleadingly tells users to check their connector settings, which are already correct.

this sounds like it could be the same root cause we saw - the PreToolUse:Callback layer matching server names with a slight mismatch. can you check if your MCP server names in settings.json exactly match what appears in the callback, including any prefix like mcp__? the "Always allow" in connector permissions operates at a different layer than the allowedTools in settings.json, so both need to be aligned.

the fact that it works in Claude Chat/Projects but not Cowork mode suggests the callback layer is applying different filtering rules per mode.

can you check if your MCP server names in settings.json exactly match what appears in the callback, including any prefix like mcp__?

One example only but every local MCP fails in Cowork:

Server naming — "quickbooks" in my claude_desktop_config.json maps correctly to mcp__quickbooks__ in the tool calls. No mismatch.

allowedTools — Every project entry has "allowedTools": []. Nothing is explicitly blocking QuickBooks or any other MCP tools.

No custom hooks — There are no user-configured PreToolUse hooks anywhere in my settings that could be intercepting calls.

No disabled servers — All disabledMcpjsonServers arrays are empty across every project.

Config is pretty clean.

Thanks for the detailed debug info. Since the naming maps correctly and allowedTools is empty (which should mean everything is allowed), and there are no custom hooks, this looks like it might be a bug in how Cowork mode handles the PreToolUse callback for MCP tools specifically.

A few things to try:

• Check if the same MCP tools work fine in regular (non-Cowork) mode with the same settings.json
• Try explicitly adding the MCP tool pattern to allowedTools, like "mcp__quickbooks__*" to see if explicit allow overrides the block
• Look at the full error output from the PreToolUse callback to see which specific check is rejecting it

If it works in regular mode but not Cowork, that narrows it down to Cowork's permission model handling MCP tools differently.

1. Regular mode vs Cowork: Yes, the same MCP tools work fine in regular Claude Code CLI with the same ~/.claude.json config. Only Cowork mode blocks them.

1. Explicit allowedTools: I added "mcp__quickbooks__*" to the allowedTools array in ~/.claude.json under the root project entry. Restarted the session. Tool schema still loads via ToolSearch, but execution still returns "This tool has been disabled in your connector settings." The allowedTools config has no effect.

1. Full error output: The only error returned is the red warning in the thinking stream with "This tool has been disabled in your connector settings." — no stack trace, no callback name, no additional debug info is surfaced to the agent. This is the same error for every local stdio MCP server.

1. From within a Cowork session, I was able to manually spawn the MCP servers via bash and successfully complete full JSON-RPC handshakes — initialize, tools/list, and tools/call all returned valid data from live APIs. The MCP servers are fully functional. The block seems to be happening somewhere in Cowork's native MCP tool routing, between ToolSearch discovering the tool schema and the actual tool execution.

Sounds like Cowork mode has its own tool filtering layer that runs before the allowedTools config gets checked. The fact that schema loads fine but execution gets blocked suggests the restriction is at the PreToolUse callback level specifically in Cowork.

Have you tried checking if there's a separate cowork-specific config or connector settings that override the user-level allowedTools? Might be worth filing this as a separate issue specifically about Cowork mode ignoring allowedTools config.

Thanks for the follow-up. Here are the results for all three tests:

1. CLI Test

Yep — the same MCP server works fine in CLI mode using --mcp-config pointed at my Desktop config. No errors.

2. allowedTools Test

Made no difference. Added mcp__[server]__* patterns to allowedTools in ~/.claude.json for my project entry. Restarted the session. Tool schemas load into the session, but execution is still blocked.

3. Full Error Output

Every local stdio MCP server returns the same error:

PreToolUse:Callback hook blocking error from command: "callback":
This tool has been disabled in your connector settings.

Net result

• Works in Cowork: Built-in tools (cowork, scheduled-tasks, session_info, mcp-registry) and Desktop Extensions registered via the Connectors UI
• Blocked in Cowork: Every stdio MCP server defined in claude_desktop_config.json — all return the identical error above
• Works in CLI: The exact same stdio servers with the exact same config work fine via claude --mcp-config

The block happens at the PreToolUse:Callback hook — after schemas are loaded but before execution. No MCP log files are created for the blocked servers.

This is reproducible across multiple different stdio MCP servers on my machine. The issue seems to be specific to Cowork mode.

interesting that CLI mode works fine with the same config. that really narrows it down - the PreToolUse:Callback hook is specific to Code mode (the IDE extension), not the CLI. a few things to check:

1. do you have any VS Code extensions that might register a PreToolUse callback? some security or policy extensions hook into this
2. check if there's a .claude/settings.json at the workspace level that might override your global settings
3. try running with CLAUDE_DEBUG=1 in Code mode to see which callback is actually blocking the execution

the fact that schemas load but execution fails suggests the MCP connection is fine, it's something in the tool approval pipeline rejecting the call after schema resolution.

Same issue on version Claude 1.2.234 (2d1855) 2026-04-01T07:58:22.000Z reported in Issue #42453
MCP server type: node

Sometimes I think I’m imagining the whole thing, but every time I go back to cowork and try to spin up the MCP I get the same errors even after all the updates that have occurred in the meantime.

I’ve basically stopped using MCP’s and have asked the agents to use CLI command commands instead as well as a skills.md file as a workaround. It seems to be fine but doesn’t have the same robust framework that the MCP provides.

It used to work for me until yesterday. Worst part of it is that local MCP server I used was a huge part of my daily workflow with claude desktop app. Cowork is mostly pointless for me without that MCP connector. I will try to build MCPB in the meantime to see if that will be different.

So I pack my MCP server into MCPB package, install that, and it start working inside Cowork! I hope this will not be temporary

Same root cause tracked in #42453 — local stdio MCP tools blocked at the Cowork PreToolUse hook. Consolidating signal there.

Closing for now — inactive for too long. Please open a new issue if this is still relevant.