[BUG] Desktop: Workflow tool (/deep-research) entirely absent after migrating to a new Mac — terminal CLI on same machine works fine

Summary

On the Claude Desktop app (macOS), the Workflow tool that powers /deep-research and dynamic workflows is completely absent from the session's tool surface — not just uninitiable via / autocomplete (as in #65206), but not exposed as a callable tool at all (confirmed via direct tool-schema introspection from inside the session). This regressed after migrating to a new Mac via Migration Assistant: it worked in Claude Desktop on the previous machine. On this same new Mac, the standalone terminal CLI (same account) has the Workflow tool and runs /deep-research successfully.

Environment

• macOS: 26.5.1 (build 25F80)
• Claude Desktop app: 1.30096.5
• Desktop-embedded Claude Code runtime: 2.1.229 (~/Library/Application Support/Claude/claude-code-vm/2.1.229/)
• Terminal Claude Code CLI (separate npm-global install): 2.1.233
• Plan: Claude Max (organizationType: "claude_max")
• Migration context: this Mac was set up via Migration Assistant from a previous Mac. ~/Library/Application Support/Claude/ and ~/.claude/ both carry an original creation timestamp of 2026-06-26 (from the old machine); /Applications/Claude.app itself shows 2026-08-14 (reinstalled/redownloaded on the new machine); systemmigrationd / SystemMigration.framework activity appears in /var/log/install.log on 2026-08-16 — consistent with the migration happening the day before this was noticed.

What I checked

Ruled out: stale bundled runtime. The Desktop-embedded 2.1.229 binary has the full deep-research workflow definition and WorkflowTool implementation compiled in (verified with strings on the binary) — identical capability to the terminal's 2.1.233 build. Not a version-lag issue.

Ruled out: local settings/account gating. Traced WorkflowTool.isEnabled through its dependency chain in the binary: not manually disabled (disableWorkflows absent everywhere on disk), org policy allows it, the account-wide GrowthBook flag tengu_workflows_enabled is cached true in ~/.claude.json, and no enableWorkflows override exists anywhere that would let a stricter tier default apply. Every local/account signal traces to "should be allowed."

Checked, and disproved, a specific-flag theory from #82270. ~/.claude.json cached "tengu_sorrel_avocet": false — the exact flag #82270 identifies as gating the deep-research bundled workflow specifically. I disproved this as the actual blocker for this account: invoking Workflow({name:"deep-research", args:"..."}) through the terminal CLI on this same machine, same account launched successfully with a real run ID and no error. So the account is currently entitled server-side; the gap is specific to the Desktop app's own runtime, not an account-level flag.

Confirmed via live tool introspection, in an actual Desktop session (CLAUDE_CODE_ENTRYPOINT=claude-desktop): no tool named Workflow, RunWorkflow, or SlashCommand is exposed at all — not present to search, let alone invoke. This is a stricter absence than #65206 describes (that report says /workflows at least opens the run manager; in this session there is no workflow-related tool surface whatsoever).

Why this looks like a migration-specific regression, not (only) the general bug in #65206

#65206 and #82270 both describe workflow-initiation gaps on accounts that, as far as those reports say, never worked. This report has a working-then-broken data point: it worked in Claude Desktop on my previous Mac, and stopped after migrating. The terminal CLI — a separate, independently-updating npm install — works correctly on the same new machine, which argues against a general account/OS/hardware problem and points instead at the Desktop app's own embedded runtime failing to properly re-establish some entitlement or cache state after a Migration Assistant transfer, while the terminal's independent install path doesn't have this problem.

Question for Anthropic

Is Desktop's embedded runtime expected to re-validate/refresh workflow entitlement after a machine migration, and if so, what could cause that to silently fail rather than surface an error? Everything client-side inspectable says this should work; I don't have visibility into what else Desktop's runtime does or doesn't refresh after a migrated install.

Related

• #65206 — same category of bug (Desktop workflow initiation unwired), closed by the inactivity bot, never fixed or acknowledged by staff
• #82270 — identifies tengu_sorrel_avocet as a per-workflow gate; present in this account's cache but demonstrated not to be the actual blocker here (see above)

Happy to provide more diagnostic detail (binary strings output, the full isEnabled call-chain trace, .claude.json excerpts) if useful.