Plugin PostToolUse hooks still silently skip in Claude Desktop / Cowork (re-filing closed #51904)

@bogini - tagging you since you've actively triaged real hook bugs (e.g. #58637). The prior reports of this bug have all been auto-closed for inactivity by the stale-bot, without any engineering response. Re-filing with 7+ weeks of additional evidence.

Re-filing context

This issue was previously reported as:

• #27398 (Feb 2026) - closed as duplicate of #16288
• #51281 (April 2026, French) - bot-closed, stale
• #51904 (April 2026, our prior report) - bot-closed May 27, stale, no engineering response in 5 weeks

#16288 remains open as the canonical "plugin hooks not loaded from external hooks.json" thread, but it conflates two distinct bugs:

1. The CLI race condition documented by @Hellblazer's binary analysis (runAgent calls executeSubagentStartHooks without awaiting loadPluginHooks())
2. The Cowork/Desktop spawn-flag exclusion (--setting-sources user excludes plugin scope entirely)

This issue is specifically about #2.

Summary

PostToolUse hooks defined in a plugin's hooks/hooks.json fire reliably in Claude Code CLI but never fire in Claude Desktop / Agent Mode (Cowork) sessions, despite the plugin being correctly installed via the admin console.

Environment

• OS: Windows 11
• Claude Desktop: 1.1.4088
• Plugin distribution: admin console "Installed by default" (enterprise)

Plugin structure

my-plugin/
├── .claude-plugin/plugin.json
└── hooks/
    ├── hooks.json   # PostToolUse matcher: "Skill"
    └── log_event.py # POSTs telemetry to external endpoint

Empirical evidence (6 weeks of production data)

We deployed this telemetry hook to ~100 users in mid-April. Across 6 weeks of usage:

• CLI / IDE sessions: hook fires correctly, every invocation captured
• Claude Desktop / Agent Mode sessions: zero events captured, ever
• Same machines, same users, same plugin version - the difference is strictly the client surface

The asymmetry is impossible to explain via random/intermittent dispatch failure. It is 100% consistent and binary - one surface works, the other never does.

Why the existing workarounds in #16288 are insufficient

Two community workarounds have been posted on #16288:

1. @xg-gh-25's install-time settings.json merge - generate plugin hooks into ~/.claude/settings.json at install time. Works for CLI but @priyankabot reported on May 17 that even user-scope settings.json hooks do not fire in Cowork. So the workaround doesn't actually cover the Cowork case.

1. @averydev's "mandatory script calls in skill instructions" - relies on agent compliance (the model choosing to run the script). Under token pressure or long context, compliance degrades. Not suitable for observability/telemetry where guaranteed execution is required.

For enterprise plugin deployment via admin console, neither workaround is viable.

Business impact

We are running an organization-wide internal plugin (~100 users) for skill adoption tracking. Six weeks in:

• Engineering / CLI power users: telemetry working, ~6-12 daily active
• Non-technical users (the majority - marketing, CS, sales, HR): exclusively on Desktop / Cowork → completely invisible in adoption data
• We cannot make data-driven decisions about which skills to invest in or which teams need onboarding help

Steps to reproduce

1. Install a plugin via admin console with hooks/hooks.json containing a PostToolUse matcher on Skill
2. In Claude Desktop / Agent Mode, invoke any skill from that plugin
3. Hook script is never invoked (no stdout/stderr, no network call, no error)
4. Open Claude Code CLI on the same machine, same user, same session
5. Invoke same skill → hook fires correctly

Asks

1. Confirm priority/timeline on a fix for the Cowork --setting-sources user exclusion. This has been a known issue since at least Feb 2026 (#27398).
2. Stop the auto-stale-bot from closing this class of issue - 3 separate community reports auto-closed by the bot without engineering response is degrading signal quality on a real platform bug.
3. If a fix is not imminent, document an officially-supported workaround for enterprise plugin deployments that need guaranteed hook execution in Desktop/Cowork.

Related

• #16288 (open canonical)
• #27398 (closed, contains cowork_vm_node.log evidence of --setting-sources user)
• #51281 (closed, French sibling)
• #51904 (closed, our prior report)

Note on our hook implementation

To be a good citizen, we have since updated our hook to filter tool_name == "Skill" before logging anything (some non-Claude-Code agent runtimes like VS Code Copilot apparently interpret our PostToolUse matcher permissively and fire on read_file, grep_search, etc.). The empirical evidence above is from logs filtered to only confirmed Skill tool invocations.