ultraplan / ultrareview commands not visible despite eligibility

Found 2 possible duplicate issues:

1. https://github.com/anthropics/claude-code/issues/49314
2. https://github.com/anthropics/claude-code/issues/16846

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

+1, same issue on an independent Max 20x account. Adding a Linux data point and some stronger evidence that should help rule out local causes.

Please don't auto-close this as a duplicate of #49314 (/buddy, unrelated command) or #16846 (/teleport, different feature and older version). This is a distinct, unresolved bug.

Environment

• Claude Code CLI: 2.1.112 (also reproduced on 2.1.111)
• Install: native (/home/<user>/.local/share/claude/versions/2.1.112), auto-update channel: latest
• OS: Linux (NixOS)
• Plan: Claude Max 20x, active
• Auth: OAuth via Claude subscription (no ANTHROPIC_API_KEY set). Relevant fields in ~/.claude/.credentials.json:
• subscriptionType: "max"
• rateLimitTier: "default_claude_max_20x"
• scopes include user:sessions:claude_code
• Claude Code Web at claude.ai/code works on the same account in the browser.

Symptoms

• Typing / and filtering ultra shows nothing. /ultraplan and /ultrareview are not registered in the command palette at session start.
• The keyword path documented at https://code.claude.com/docs/en/ultraplan (writing "ultraplan" in a normal prompt) does not trigger the feature either.
• /tasks is registered and functional, so the cloud surface itself is initialised in the session — only ultraplan / ultrareview are missing.

Ruling out local causes

I ran Claude Code with a completely isolated profile and a brand-new OAuth login to eliminate every local variable:

rm -rf /tmp/claude-clean
env -i HOME=$HOME PATH=$PATH TERM=$TERM CLAUDE_CONFIG_DIR=/tmp/claude-clean claude

That environment has:

• no settings.json,
• no hooks,
• no plugins,
• no MCP servers,
• no NODE_OPTIONS / CLAUDE_CODE_* overrides,
• a fresh OAuth session signed in with the same Max 20x account.

Result is identical — commands still absent. This rules out user configuration, plugins, hooks, MCP servers, custom env vars, or stale credentials as the cause.

Support path already exhausted

Opened a ticket with support@anthropic.com (conversation IDs 215473947107196, 215473947183070, 215473947232591). Support confirmed that the plan is Max 20x, OAuth is correct, and the configuration is fine, but the replies are automated and loop through "try claude update and restart" — which does not help because the CLI is already on the latest version and command registration is driven by the server response at session start, not local state.

Likely cause

Given that:

• the plan qualifies (Max 20x, rateLimitTier: "default_claude_max_20x"),
• the CLI is 20+ versions past 2.1.92 (where /ultraplan landed),
• the exact same symptoms reproduce on a completely clean profile,
• other Max 20x users on the same or earlier CLI versions do see the commands,

this appears to be a server-side feature-flag / entitlement not applied to some Max 20x accounts, not a client-side bug in the CLI.

Ask

Could someone from the team:

1. Confirm whether /ultraplan / /ultrareview are gated by a server-side flag that can be stuck off for some qualifying Max 20x accounts.
2. Share how affected users should get the flag enabled, since the standard support path does not seem to have visibility into this.
3. Remove the duplicate label (the linked issues are different commands/features).

Happy to provide a /doctor dump or anonymised credentials.json fields if that helps triage.

+1 same symptoms. Claude Code v2.1.112, macOS, at an eligible subscription tier.

+1 facing the same issues. I'm on Claude Code v2.1.112, macOS, at an eligible subscription tier as well.

+1, same issue here.

Environment

• Claude Code CLI: 2.1.114
• Platform: Linux

Observed

• /ultraplan is not available
• /ultrareview is not available
• claude --help | grep -i ultra returns nothing
• in-session /help also does not list /ultraplan or /ultrareview

So the problem is still reproducible on 2.1.114, not just 2.1.111.

+1 same v2.1.114, Max plan, extra usage enabled, /login fresh, still Unknown command.

Linux with 2.1.114 on a max x20 plan and I can't access this command either.

I also tried logging in again.

I am guessing we are gated because we are in the AU region. I get you have to roll things out slowly but can you at least give us a heads up and not radio silence.

Imagine if you had a tool that could be used to communicate these types of things, you know like a large language model....

@wiltaylor not in AU region

Same issue here in Canada. Windows. Claude v2.1.116. Max20 plan.

FWIW, I had the exact same issue. I checked my claude/settings.json, saw that I had DISABLE_TELEMETRY set to 1, removed that line, and now the slash commands appear when I launch the cli.

Good spot – if I remove DISABLE_TELEMETRY the command does show up. Although I’m not sure that’s a desirable trade-off.

Update: the visibility of /ultraplan and /ultrareview is controlled by a server-side dynamic config, not by anything local.

The relevant config appears to be named tengu_ultraplan_config. When its enabled is not true for a given user, the CLI never registers the command at all — /, the keyword path, and /help all miss it. /ultrareview follows the same pattern; its policy-blocked state surfaces under the telemetry event tengu_ultraplan_create_failed with reason: "policy_blocked", but that only fires if launch was attempted — affected users here never get that far.

Side note on ~/.claude/statsig/: on 2.1.11x this directory is no longer the authoritative cache. The SDK keeps evaluations in memory per process and does not recreate the directory on fresh startup. Mine was stuck at receivedAt 2026-01-31 with source: "NetworkNotModified" for 80+ days; deleting it changes nothing, and the #28777 workaround no longer applies on these versions.

Ask

1. For the accounts affected in this thread, could someone check the value of tengu_ultraplan_config (and the ultrareview analogue) and report whether enabled is true.
2. If it is false/null on qualifying plans, either enable it or share the targeting criteria — right now there is no way to tell from the user side whether we're hitting a rollout bucket, a stuck flag, or an intentional gate.

Removing DISABLE_TELEMETRY=1 did the trick for me...

Closing for now — inactive for too long. Please open a new issue if this is still relevant.