[BUG] DISABLE_NONESSENTIAL_TRAFFIC silently breaks /usage

Found 3 possible duplicate issues:

1. https://github.com/anthropics/claude-code/issues/70454
2. https://github.com/anthropics/claude-code/issues/52787
3. https://github.com/anthropics/claude-code/issues/69528

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

Not a maintainer — confirming the mechanism and adding a workaround, because this is one of a cluster of silent feature removals from the same flag.
/usage pulls your usage numbers from a server endpoint, and CLAUDE_CODE_DISABLE_NONESSENTIAL_TRAFFIC=true classifies that fetch as non-essential and suppresses it — so the call returns nothing and you get the generic Failed to load usage data. It isn't a crash; it's traffic suppression working as designed, but silently: nothing tells you the data is unavailable because you disabled the traffic. As you note, the same flag also takes out /feedback (#52787) and /web-setup (#70454), so the real issue is a category of "this command is now a no-op, with no explanation why."

• Read usage from the web instead of the CLI. Your plan/usage is visible at the Anthropic Console / claude.ai account usage page, so you don't have to relax the flag to check it. This is the right answer for an air-gapped/corporate setup where the flag is deliberate.
• Or temporarily run one session without the flag purely to check usage, then re-enable it:

``sh
env -u CLAUDE_CODE_DISABLE_NONESSENTIAL_TRAFFIC claude # this session can /usage
`
(If you export it in a shell rc, env -u overrides it for just that invocation.)
The ask here is reasonable and small: when a command is disabled by DISABLE_NONESSENTIAL_TRAFFIC, **say so** — e.g. Usage data is unavailable because CLAUDE_CODE_DISABLE_NONESSENTIAL_TRAFFIC is set, the same way /feedback is explicit about being disabled. A user who explicitly typed /usage has signalled intent; failing closed with a generic error reads as a bug even when the suppression is intentional. Documenting the full set of commands the flag neuters (/usage, /feedback, /web-setup`, …) in one place would also stop these from being filed as separate surprises.

Not macOS-specific: reproduces identically on Linux (Arch, x86_64, native build), so the platform:macos label understates the scope. Still present in 2.1.220, filed against 2.1.195.

Root cause, from the shipped bundle:

fetchUtilization() calls the first-party API helper without the bypass option:

Pi.get("/api/oauth/usage", { timeout: 5000, headers: {...}, refreshOAuth: true })

and the helper short-circuits before any request is made:

if (!opts.bypassEssentialTrafficOnly && ca()) return { ok: false, reason: "essential-traffic-only" }

That hits if (!r.ok) throw Error('Auth error: ' + r.reason), which is caught in collectUsageData() and turned into status: "unavailable", which renders the generic string.

Two things make this worse than the sibling cases in #52787 and #70454:

1. The internal error text is Auth error: essential-traffic-only, so anyone who turns on debug logging gets pointed at authentication instead of at the flag. Credentials and endpoint are fine: a direct GET /api/oauth/usage with the same stored OAuth token returns 200 with the full payload in about 0.3s.

1. DesignSync, Projects and --enable-live-preview already print an explicit "unavailable while nonessential network traffic is restricted (CLAUDE_CODE_DISABLE_NONESSENTIAL_TRAFFIC is set)" message. /usage is the only one in the group that falls through to a generic error, so surfacing reason here is a one-line change with existing precedent in the codebase.

Passing bypassEssentialTrafficOnly on this call would also be defensible: the endpoint returns the user's own plan rate limit state and sends no workspace content.