[BUG] Cowork (Windows, host-loop): every mcp__workspace__bash call denied since Claude Desktop 1.44121.1 / Claude Code 2.1.258 — the app's own --disallowedTools Bash now matches the workspace shell via toolAliases

Preflight Checklist

• [x] I have searched existing issues and this hasn't been reported yet
• [x] This is a single bug report (please file separate reports for different bugs)
• [x] I am using the latest version of Claude Code

What's Wrong?

mcp__workspace__bash with any command — even echo ok — returns Permission to use mcp__workspace__bash has been denied. No permission prompt is ever emitted (main.log shows no Emitted tool permission request for the tool). audit.jsonl records:

{"type":"system","subtype":"permission_denied","tool_name":"mcp__workspace__bash","decision_reason_type":"rule", ...}
and the transcript has "toolDenialKind":"permission-rule". The SDK init message still lists mcp__workspace__bash in tools, and the SDK logs [CLAUDE_SDK_CAN_USE_TOOL_SHADOWED] ... mcp__workspace__bash (it is a bare allowedTools entry). The VM itself is healthy (vm_boot completed, Network status: CONNECTED, API reachability: REACHABLE).

What Should Happen?

--disallowedTools Bash / the pushed permissions.deny: ["Bash", "WebFetch"] must not be applied to the alias targets the host itself declares (mcp__workspace__bash, mcp__workspace__web_fetch), or the app must stop passing the aliased built-ins as deny rules (filter like Nc() does).

Error Messages/Logs

Steps to Reproduce

Root cause (from the shipped bundles)

For every Cowork session the desktop app spawns the CLI with (captured from the live process): --disallowedTools Bash,PowerShell,NotebookEdit,REPL,JavaScript,WebFetch,AskUserQuestion,... --allowedTools ...,mcp__workspace__bash and passes toolAliases: { Bash: "mcp__workspace__bash", WebFetch: "mcp__workspace__web_fetch" } (app.asar: e.disallowedTools=[...e.disallowedTools??[],...t.wS]; e.toolAliases={Bash:t.eC,WebFetch:t.tC} — identical in 1.37937 and 1.44121).
Claude Code 2.1.258 evaluates bare deny rules alias-aware: bs(e,n,r) → PJe(n,o,{...,toolAliases:e.toolAliases}) → dl() matches a rule whose toolName is Bash against the tool mcp__workspace__bash, returning the bare message via M0(): Permission to use ${e.name} has been denied. with decisionReason:{type:"rule"}. This is the behavior now documented on the permissions page ("Claude Code also applies deny rules that name the whole Bash or WebFetch tool to these Cowork tools"). With 2.1.255 the same --disallowedTools Bash did not match the workspace tool.
1.44121 additionally adds a post-spawn push (feature hostLoopPathRulesOverStdin, id 1978029737): applyFlagSettings({permissions: hl(W, hostLoopAllowedToolsAtSpawn)}) where hl(e,t) = {allow:[...t], deny:[...e.disallowedTools], ...} — the deny list is pushed unfiltered (the managed-tier converter Nc() filters aliased tools out via !Object.hasOwn(toolAliases, e), hl() does not). Log marker new since 17:06:56: [HostLoop] spawn argv ~1636 chars; 31 of 42 allow rules on argv.
Net effect: Cowork's own "hide the built-in Bash/WebFetch" deny now denies Cowork's own shell (and presumably mcp__workspace__web_fetch).

Claude Model

Other

Is this a regression?

Yes, this worked in a previous version

Last Working Version

_No response_

Claude Code Version

1.44121.1

Platform

Anthropic API

Operating System

Windows

Terminal/Shell

Windows Terminal

Additional Information

Timeline (local time, 2026-09-02)

16:15:38 last successful vmOneShot ... bash (ditto session)
16:54–17:05 update downloaded/staged; 17:05:43 beforeQuitForUpdate; 17:05:48 Starting app 1.44121.1; 17:05:53 CLI 2.1.258 download
17:06:56 first [HostLoop] spawn argv ... allow rules on argv (new code path)
17:07:48 first permission_denied for mcp__workspace__bash; 0 successful bash calls in any Cowork session since