[BUG] /deep-research fails with misleading parse error when feature flag is absent — should surface a clear availability message

Summary

/deep-research (and Workflow({name: "deep-research"})) fails 100% of the time in the CLI with a misleading parse error. The GrowthBook feature flag tengu_sorrel_avocet — observable in ~/.claude.json under cachedGrowthBookFeatures — appears to gate the deep-research bundled workflow. This flag is not present in our account's cached features, even after a confirmed successful cache refresh. General workflows and custom workflow scripts work perfectly.

The core bug is the error message: when a bundled workflow is unavailable due to a missing feature flag, the user sees a confusing parse error instead of a clear availability message.

Environment

• Claude Code: 2.1.220 (native install, macOS, Apple Silicon)
• Plan: Max
• tengu_workflows_enabled: true (general workflows work)
• tengu_sorrel_avocet: not present in cachedGrowthBookFeatures

Steps to reproduce

1. Open a CLI session (standalone, not desktop Code tab).
2. Invoke /deep-research "any question" — or have the model call Workflow({name: "deep-research", args: "any question"}).
3. Observe the error:

``
Error: Invalid workflow script: 'export const meta = { name, description, phases }'
must be the FIRST statement in the script
``

1. Run any custom Workflow({script: "export const meta = {...}; ..."}) — it succeeds, confirming the workflow engine itself is fine.

Analysis

Behavioral testing suggests that named-workflow resolution for deep-research is keyed to the tengu_sorrel_avocet feature flag:

• Inspecting ~/.claude.json shows tengu_workflows_enabled: true but tengu_sorrel_avocet is absent
• Temporarily removing CLAUDE_CODE_DISABLE_NONESSENTIAL_TRAFFIC=1 and launching a fresh subprocess caused the flag cache to refresh (observed flag count: 278 → 442), but tengu_sorrel_avocet remained absent — indicating the flag is not assigned server-side to this account
• Without the flag, the workflow script is apparently never registered, so the name lookup passes an empty/invalid payload to the parser, producing the misleading export const meta error
• Reproduced consistently: 0/8 attempts succeeded across 4 separate sessions on v2.1.220

Impact

• /deep-research is completely unusable on this account
• Zero tokens are consumed per attempt (fails at the parse phase before any agents launch)
• The error message is actively misleading — it blames script syntax when the actual cause is the workflow not being registered. Users waste significant debugging time chasing a non-existent syntax problem.
• Workaround: hand-writing an equivalent workflow script works, confirming the issue is isolated to name-based resolution

Related issues

• #65206 — Same symptom pattern (deep-research unavailable despite workflows being enabled) on desktop Code tab; this report covers the CLI
• #63540 — Same category of misleading error framing: workflow parse errors unconditionally blame "TypeScript syntax" regardless of actual cause

Suggested improvements

1. Error message (the actionable bug): When a named workflow's gate flag is absent, surface a clear message — e.g., "Workflow 'deep-research' is not available for your account" — instead of the misleading parse error. This aligns with the concern raised in #63540 about misleading error attribution.
2. Availability question: Is the tengu_sorrel_avocet gating intentional for certain accounts/plans, or is this an unintended gap in the rollout? If intentional, documenting the eligibility criteria would save users from debugging a non-bug.