[BUG] Cowork sessions ignore user hooks and managed settings — sandbox platform mismatch breaks all settings resolution

Found 3 possible duplicate issues:

1. https://github.com/anthropics/claude-code/issues/39889
2. https://github.com/anthropics/claude-code/issues/39125
3. https://github.com/anthropics/claude-code/issues/33613

This issue will be automatically closed as a duplicate in 3 days.

• If your issue is a duplicate, please close it and 👍 the existing issue instead
• To prevent auto-closure, add a comment or 👎 this comment

🤖 Generated with Claude Code

This is not a duplicate of any of the three flagged issues. Here's why:

#39889 — Covers Dispatch (mobile-spawned) sessions ignoring model/permission settings. Different feature (Dispatch, not Cowork), different root cause (Electron env stripping vs. VM sandbox platform mismatch). That issue doesn't mention hooks, managed settings, or the Linux VM platform detection problem.

#39125 — Covers user_config env vars not being injected into MCP server processes in cowork. While it shares the sandbox isolation theme, it's specifically about MCP credential template resolution (${user_config.ct_username}), not about user hooks, managed/MDM policy settings, or the process.platform mismatch that causes the binary to look at /etc/claude-code/ instead of /Library/Application Support/ClaudeCode/.

#33613 — Covers managed-settings.json being bypassed in VSCode + remote-SSH. Completely different execution context (VSCode extension deploying a binary to a remote host) with a different root cause (remote host doesn't have the managed-settings file). Our issue is about the Cowork VM sandbox where the file exists on the macOS host but the binary inside the Linux VM resolves to the wrong platform-specific path.

What this issue uniquely documents:

1. The process.platform mismatch: the Cowork Linux VM causes managed settings to resolve to /etc/claude-code/ (doesn't exist) instead of using the macOS host's /Library/Application Support/ClaudeCode/ (exists and works for CLI sessions)
2. The cowork_settings.json file that the binary explicitly looks for in cowork mode (via the isCowork() check) but that is never created by the sandbox launcher
3. The three root causes are independently verified from inside the sandbox with concrete evidence (env vars, filesystem checks, decompiled binary logic)

These are related issues in the broader "sandbox isolation breaks settings" category, but they have distinct root causes and require distinct fixes.

Production impact: enforcement engine blocked by this bug

Platforms affected: Windows (host), Linux (Cowork sandbox), macOS (same sandbox architecture)

I'm running an autonomous platform orchestration layer on Cowork — Windows 11 host, Linux sandbox (where Cowork actually executes), PostgreSQL backend on Hetzner VPS, 9 agents via OpenFang, deployment pipelines, scheduled tasks. On the Claude Code side (Windows), I have a 55-rule enforcement engine (enforcement-engine.ps1, 2,500 lines) with hash-chained tamper-proof logging that runs via PreToolUse hooks on every tool call. Exit code 2 = hard block. The model physically cannot bypass it.

In Cowork, none of this works — on any host OS. The sandbox is a Linux VM regardless of whether the host is Windows, macOS, or Linux. Hooks silently don't fire. The enforcement engine can't run. Every constraint becomes advisory text loaded at session start that the model follows voluntarily.

What actually happened

During a Cowork session today, I had the model implement six features (tiered memory loading, lease-based task queues, cost estimation, provider abstraction, tool taxonomy, verbatim context storage). The model wrote the code, ran e2e tests locally, verified syntax — then stopped. It said "the file watcher should auto-deploy on next git push" without actually committing or pushing anything. The code sat on disk, unreachable by the production server.

The constraint banning that exact behavior (constraint:no_guessing_deploy_state) was filed to PostgreSQL by the model itself, 10 minutes earlier, in the same session. Knowledge wasn't the problem. There was no enforcement mechanism to execute it.

On Claude Code, this can't happen — R-049 in the enforcement engine pattern-matches deploy-related tool calls and blocks anything that doesn't go through the deploy gate. In Cowork, that rule is just text.

What I built as a workaround

I exhausted every alternative before arriving here:

1. MCP Gateway — can't intercept built-in tools (Read/Write/Edit/Bash). Dead end.
2. Post-hoc audit via scheduled tasks — catches violations after the fact, doesn't prevent them.
3. Self-checkpoint protocol in CLAUDE.md — still advisory. Model can skip it.
4. Skill as enforcement wrapper — skills are context enrichment, not gates.
5. Hybrid: gate script + audit + user-visible stamp — best available. Built implementation-gate.py that outputs binary PASS/FAIL for syntax/commit/push/deploy/PG-status checks. ~80% effective. Not mechanical.

The gate script works:

═══════════════════════════════════════════════
  IMPLEMENTATION GATE
═══════════════════════════════════════════════
  ✅ push: PASS (9296ffbdddab)
  ✅ deploy: PASS
  ✅ pg:opp:opp-087: PASS
  ...
  GATE: ✅ PASS (8 passed)
═══════════════════════════════════════════════

But the model can still skip running it. Nothing forces the call. That's the gap only a PreToolUse hook can close.

Why fixing this bug matters beyond my use case

This isn't just about my platform. The fundamental issue is: Cowork is positioned as an autonomous agent, but autonomy without enforcement is a liability. The model-behavioral safety layer ("trained to follow rules") is necessary but not sufficient for workflows where mistakes have real consequences — deploying broken code, skipping security checks, sending messages to real clients (see also #41184 where MSApps hits the same wall running 200+ Cowork sessions with 54 scheduled tasks in production).

The hook infrastructure already exists in Claude Code. The three root causes you identified (settings file not mounted, platform mismatch on managed settings path, env vars not forwarded) are all sandbox configuration issues, not missing architecture. Fixing them would immediately unlock mechanical enforcement for every Cowork user running production workloads.

What I'd build the day this ships

The enforcement engine is already written. The rule patterns are in PostgreSQL. The moment PreToolUse fires in Cowork, I wire it to the same gate:

{
  "hooks": {
    "PreToolUse": [{
      "matcher": "Bash|Write|Edit",
      "hooks": [{
        "type": "command",
        "command": "python3 scripts/enforcement-gate.py"
      }]
    }]
  }
}

55 rules, dynamic pattern loading from PG, hash-chained audit log — all functional on day one. The code exists. The sandbox configuration is the only blocker.

+1 on this. Adding a concrete use case from the feature request side:

I have a SessionStart hook in ~/.claude/settings.json that mounts Google Drive and runs a session-autoload skill to restore persistent memory from an Obsidian vault. Works perfectly in CLI. In Cowork, it silently does nothing.

The only workaround is putting the same instructions in CLAUDE.md as a "BLOCKING" directive, but Claude routinely ignores it in favor of answering the user's first message. So the real workaround is training myself to type "boot up" as a throwaway first message every session — which defeats the purpose of having a hooks system.

This isn't just a convenience issue. Without SessionStart hooks, there's no reliable way to initialize session context in Cowork. CLAUDE.md is advisory, scheduled tasks don't have a "session start" trigger, and skills only fire when explicitly invoked. Hooks are the only mechanism that would actually solve this.

Prioritizing the fix for Root Cause 1 (mounting settings.json into the sandbox) would unblock this entire class of use cases.

+1 on this. Adding a concrete use case from the feature request side: I have a SessionStart hook in ~/.claude/settings.json that mounts Google Drive and runs a session-autoload skill to restore persistent memory from an Obsidian vault. Works perfectly in CLI. In Cowork, it silently does nothing. The only workaround is putting the same instructions in CLAUDE.md as a "BLOCKING" directive, but Claude routinely ignores it in favor of answering the user's first message. So the real workaround is training myself to type "boot up" as a throwaway first message every session — which defeats the purpose of having a hooks system. This isn't just a convenience issue. Without SessionStart hooks, there's no reliable way to initialize session context in Cowork. CLAUDE.md is advisory, scheduled tasks don't have a "session start" trigger, and skills only fire when explicitly invoked. Hooks are the only mechanism that would actually solve this. Prioritizing the fix for Root Cause 1 (mounting settings.json into the sandbox) would unblock this entire class of use cases.

Another +1. Same exact use case.

Another +1. Same exact use case.

+1 - there are so many use cases to apply and to make Cowork a greater companion for all.

Another +1. Same exact use case.

+1 - same issue. Beyond enterprise managed-settings concerns, this means any third-party integration that relies on UserPromptSubmit is non-functional for desktop-app users today. The docs at https://code.claude.com/docs/en/desktop-quickstart state that desktop "shares configuration (CLAUDE.md files, MCP servers, hooks, skills, and settings)" - which set expectations that don't match the current Cowork behavior. A footnote in the hooks reference clarifying the Cowork limitation would help vendors set correct customer expectations until the underlying mount/path issue is fixed.

+1 Same use case here. We need to be able to reliably use these hooks in enterprise deployments. Is there any update on this?

+1 same use case, we need this for org level deployment.

+1 for same use cases that hooks within cc are needed

+1 confirming this bug on Claude Cowork Windows as well — ~/.claude/settings.json user-scoped hooks never fire inside Cowork sessions on the Windows host, mirroring the macOS reproduction in the issue body.

Environment

• Claude Desktop (Cowork mode) on Windows 11 Pro
• Same symptom: cowork_settings.json referenced by WK5() / getSettingsFilename() does not exist in the sandbox; user's actual C:\Users\<user>\.claude\settings.json on the Windows host is never mounted into the VM
• 6 consecutive sessions verified S69 → S74 (2026-05-26 to 2026-05-27)

Architectural impact (Empire trading project, multi-PC workflow)

This bug materially constrains what teams can deploy at user-scope. We discovered #40495 during S69 deep research while designing an internal ADR (ADR-022 — M4.4 hooks USER-GLOBAL) that would have added Empire-grade safety hooks at ~/.claude/settings.json:

• 5/6 layer defense-in-depth (SessionStart, SessionEnd, PreToolUse Bash/PowerShell tiered DENY/ASK/ALLOW, PostToolUse JSONL audit, UserPromptSubmit) targeting destructive ops across 10+ Empire repos
• Pre-Mortem identified #40495 OPEN → forced scope restriction to Claude Code CLI sessions ONLY
• 4 bash MVP scripts staged but explicitly NOT deployed to Cowork — we know they would silently no-op there

Net architectural cost: defense-in-depth ONLY active in Code CLI (where Luke runs git/commit/push), Cowork sandbox bypasses entirely. This is workable for our threat model (Cowork is draft/review surface, not destructive), but unexpected for users assuming "user-scope = always fires".

Cross-cluster — broader Cowork hook subsystem issue?

| Issue | Hook scope | Cowork-Windows status |
|---|---|---|
| #40495 (this) | user-scope (~/.claude/settings.json) | ❌ entirely ignored |
| #22449 / #39550 family | plugin-scope (${CLAUDE_PLUGIN_ROOT} PostToolUse) | ⚠️ fires but with literal-as-dirname expansion bug (Cowork-Windows variant — separate comment filed) |
| #27398 | plugin hooks --setting-sources user exclusion | OPEN |
| #18610 | Plugin hooks Windows /bin/bash path | OPEN |
| #21468 | Plugin SessionStart Windows | OPEN |
| #38699 | local marketplace plugins inconsistent | OPEN |

Suggests Cowork's settings resolution + sandbox mount + variable substitution form a single subsystem that diverges from native Claude Code CLI semantics across user-scope, plugin-scope, and platform-specific paths.

Documentation gap suggestion

If user-scope hooks are intentionally bypassed in Cowork (sandbox isolation by design), the docs should state this explicitly — currently ~/.claude/settings.json is documented as the canonical user-config location without Cowork qualifier. Users designing safety architectures need to know upfront which scopes are valid in which environments.

Resolution suggestions (priority order)

1. Lowest cost: docs update explicitly stating Cowork sandbox does not consume user-host ~/.claude/settings.json (and which features that affects)
2. Middle: mount user-host ~/.claude/settings.json read-only into Cowork sandbox so user hooks DO fire (matches user expectation, opt-in via Cowork settings UI)
3. Long-term: unified settings resolution layer across Code CLI + Cowork so feature parity is the default not the exception

Empire reproducibility: architectural impact confirmed across 6 sessions. Happy to share ADR-022 design doc + scope-restriction rationale if useful as a real-world architectural workaround case study.

The three root causes you articulate (user settings file absent in sandbox, managed-settings unreachable, env vars unset) match the pattern I've been tracking across a separate cluster of 195 Cowork-shape issues filed in the 14 days from 2026-05-14 to 2026-05-28 (cluster framing notes in cc-safe-setup/docs/cluster-tracker.html for context, not a sales pitch — the tracker is a free reference).

The hook-side defense surface is structurally narrow because, as you note, hooks defined in ~/.claude/settings.json cannot fire inside the Cowork sandbox itself. What is reachable is the CLI on the same machine — operators who use both CLI and Cowork can get an automated reminder, on the CLI side, that captures the standing instructions and surfaces them to the operator before they switch to Cowork.

I shipped three CLI-side hooks today (2026-05-28) that cover the three most concrete sub-shapes I could verify:

1. cowork-claude-md-load-checker — SessionStart hook that surfaces ~/.claude/CLAUDE.md at every CLI session start with an explicit Cowork-side reminder block. Directly addresses #62859 (the CLAUDE.md sub-case of the broader pattern you describe).
2. cowork-fuse-staleness-watcher — PreToolUse Bash matcher hook for the FUSE mount silent-corruption variant (#62932 P1).
3. cowork-model-picker-advisor — SessionStart hook for the silent Sonnet 4.6 [1M] default in the Cowork picker (#62949).

All three are advisory-only (always exit 0), file-skip silently when not applicable, and ship with their respective test files (20 / 25 / 25 cases passing). A pre-existing cowork-claudemd-helper.sh standalone script (#403, 40 tests) covers the case where the operator wants to paste CLAUDE.md content directly into a Cowork chat.

The standing recommendation that emerges from the cluster framing: until Cowork resolves the settings-resolution gap, treat Cowork sessions as a separate trust boundary from CLI sessions and rebuild the operator's intent (CLAUDE.md, managed policies, env settings) explicitly on the Cowork side at the start of each session. The CLI-side hooks above make that operator-intent visible at the CLI/Cowork boundary so it's at least obvious when the gap matters.

If anyone here wants the four artifacts as a single zero-install reference instead of the repo, I can put them in a Gist — let me know which form is most useful to you.

create hooks inside the plugin, and then upload that plugin into cowork. This worked for me.

Not a maintainer — your root-cause breakdown (sandbox CLAUDE_CONFIG_DIR, the missing cowork_settings.json, the process.platform managed-path mismatch) is more precise than anything I can add at the code level. One operator-facing angle that hasn't been called out in the thread, because it's worse than lost convenience:
**This is a silent safety failure, not just a missing-automation one. The thread's examples are mostly SessionStart automation (mount Drive, restore context). But the same resolution gap means any PreToolUse safety guard** silently doesn't fire in Cowork either — the hooks people use to block rm -rf / git push --force / production-DB writes / git reset --hard. So an operator who has carefully set those up will run a Cowork session believing they're protected, and the protection isn't there. The failure is invisible until a destructive call that "should have been blocked" goes through. A guard that's silently inert is more dangerous than no guard, because it removes the caution you'd otherwise keep.
Operator mitigation until this is fixed:

• Treat Cowork sessions as hook-free / unguarded. Don't assume your ~/.claude/settings.json safety rules apply there.
• Run anything guard-dependent or irreversible (destructive git, prod-touching commands, bulk deletes) from the regular claude CLI, where user hooks do resolve and fire — not from the Cowork tab.
• If you want to confirm the state for your own setup: add a trivial canary to a PreToolUse (or SessionStart) hook that appends a timestamp to a log file, then compare a CLI session against a Cowork session. If the Cowork run never writes the line, your guards are inert there — which matches the resolution bug you traced.

The enforcement-engine and compliance impact others raised is the same root issue seen from the policy side: if managed settings don't resolve in the sandbox, nothing server-pushed is actually enforced on Cowork activity, so an audit that assumes managed policies are in effect is reporting a state that isn't real.

create hooks inside the plugin, and then upload that plugin into cowork. This worked for me.

@Saurav-Sutaria

thanks for posting that — we tried to reproduce it and couldn't, so hoping you can help pin down what's different.

Our test: a minimal plugin (.claude-plugin/plugin.json + hooks/hooks.json) with a single UserPromptSubmit command hook that unconditionally returns {"decision":"block","reason":"..."} — no network, no script, just an inline printf. Uploaded via Customize → Plugins, confirmed enabled, started a fresh Cowork session, typed hi → Claude answered normally, the hook never fired. Same result with a real curl-based hook.

Could you share:

1. Which hook event did you use — UserPromptSubmit, SessionStart, PreToolUse, something else? (We're specifically after UserPromptSubmit.)
2. Where exactly did it fire — a true Cowork session, or the desktop app's "Claude Code" tab? (They behave differently re: settings/hooks.)
3. Hook type — command, prompt, or agent?
4. How did you install the plugin — "upload a custom plugin file", a marketplace (/plugin marketplace add), or --plugin-dir?
5. App version + OS, and roughly when you tested.
6. How did you confirm it fired — what visible effect did you see, and did it persist across a fresh session?

A copy of your hooks.json (redacted) would be hugely helpful. Trying to figure out whether this is a version thing or a config difference. Thanks!

Same symptom on Windows, which may mean this is not limited to the macOS / Linux-sandbox path described in the original report.

Environment

• Claude desktop app 1.24012.11 (Microsoft Store build), Windows 11 Pro
• Claude Code 2.1.219 (bundled with the desktop app)
• The Claude Code CLI is not installed as a separate program (claude --version is not a recognized command in the user's own PowerShell), so nothing else could be applying these settings.

What I observed (tested 2026-08-03)

PreToolUse hooks configured in ~/.claude/settings.json never fire:

1. Write of a file containing api_key = "sk-..." → the hook should return deny; the file was created with no prompt.
2. Piping the same JSON payload directly into the hook script on stdin → it correctly returns permissionDecision: "deny", so the hook script itself works.
3. A PowerShell command touching .claude/hooks/... → the hook should return ask; it ran with no prompt.
4. A WebSearch whose query contained api_key=... → should deny; the search ran.

I then created the same hook configuration as a project-level <project>/.claude/settings.json and retested in a fresh conversation — all of the above still passed through unblocked. So neither user settings nor project settings are applied.

One detail that may narrow this down: on this machine PowerShell commands execute against the real Windows filesystem (they read and write real files on local and removable drives), so there is no Linux VM sandbox involved here. That suggests either the settings-resolution failure is broader than the platform-mismatch explanation, or a second code path leads to the same result.

Happy to run any specific check that would help.

I want to separately flag that Cowork cloud sessions do not respect managed settings hooks. Cowork Desktop ( running locally ) does respect managed settings hooks set via the organization settings under managed settings in Claude code (i.e., server managed settings), but these stop working in Cowork cloud mode which is currently in beta.

See screenshot below for Claude's own investigation from within its cloud sandbox.

<img width="767" height="640" alt="Image" src="https://github.com/user-attachments/assets/8f87f4f7-1dea-4585-bda3-1a4a30422480" />

I wish we could get an understanding of how important is this for Anthropic to fix this. We really rely on this.

Adding operational data from a Windows x64 Cowork deployment, since this issue is still open with no maintainer response and the impact is larger than "hooks do not fire".

Scale of what silently does not run. We maintain 50+ output-validation layers across two shell gates (a response scanner and a pre-send grep) plus ~20 Python validators. Every one of them is correct, tested, and optional at the moment it matters, because nothing in Cowork can invoke them on the model's own output. There is no PreToolUse to block on and no response-time hook to run them from. The gates only run when the model chooses to run them.

What that costs, measured rather than estimated. On 2026-08-13 a session produced a routine status reply with the validator directory already mounted and the scanner one command away. It did not run it. Running the same scanner on that reply afterwards produced four findings in under two seconds: a blocking inbox-aging error, an unestimated-deferral warning on a self-contradicting line, an unread-briefs warning, and three style violations. All four were catchable before send, by tooling that was present, working, and reachable. This is not a one-off; our own logs record the same shape on 2026-07-01, twice in one day.

Our workaround, and why it is only half a fix. Both gates now append to a JSONL ledger on every run, and a checker reports days with substantive work and zero gate invocations. That makes non-invocation visible after the fact. It cannot make it visible before the send, which is the only moment that matters. A gate that is skipped leaves no trace at the time it is skipped.

On the adjacent request in #63360. A Stop hook would be a real improvement for logging, but it fires after the turn completes, so it can record a bad response and cannot withhold one. For validation the useful primitive is a hook that runs on the drafted response and can block or annotate it before it reaches the user, in the same shape PreToolUse has for tools.

Concrete ask, in priority order.

1. Fire ~/.claude/settings.json hooks in Cowork at all, per the three root causes in the original report. Everything else is downstream of this.
2. Honour CLAUDE_CODE_HOST_PLATFORM when resolving managed settings rather than process.platform.
3. A response-time hook that can block, not only observe.

Happy to supply the gate ledger format or the invocation-checker if useful. Environment: Windows x64 packaged desktop app, OneDrive-backed working tree, Cowork sessions both local and cloud.