[Bug]: Claude limits warning does not explain when reads are blocked by CLAUDE_CODE_DISABLE_NONESSENTIAL_TRAFFIC

Summary

Usage → Limits displays “Claude: Could not read limits.” when Claude Code has CLAUDE_CODE_DISABLE_NONESSENTIAL_TRAFFIC enabled.

The account is authenticated and supports subscription limits. The setting blocks Claude’s usage lookup, but T3’s warning gives no indication that a local configuration is responsible.

Area

apps/server

Steps to reproduce

Sign in to Claude Code with a Claude subscription account.

Add this environment setting to ~/.claude/settings.json:

{
  "env": {
    "CLAUDE_CODE_DISABLE_NONESSENTIAL_TRAFFIC": "1"
  }
}

Launch T3 Code with the default Claude provider enabled.
Open Usage → Limits and refresh.

Expected behavior

Respect Claude’s traffic restriction and explain that it prevents subscription limits from being read. Provide an actionable diagnostic identifying the setting.

Actual behavior

T3 displays:

Claude: Could not read limits.

The warning does not identify the configuration responsible or explain how to restore limits while keeping telemetry disabled.

Environment

Windows 11 Pro, build 10.0.26200, x64
T3 Code Nightly 0.1.6-nightly.20261030.3917
Backend failure also reproduced from an unmodified checkout at 305a90dce44b8b7813d951662f13ce8510a3c669
Claude Code 2.1.314
@anthropic-ai/claude-agent-sdk 0.3.276
Claude Pro subscription

Investigation and verification

The existing T3 capabilities probe authenticated successfully but received:

{
  "rate_limits_available": true,
  "rate_limits": null
}

T3 maps this response to probeFailed, which produces the generic warning.

A single direct, authenticated read of Anthropic’s usage endpoint returned HTTP 200 with limit data. A temporary CLI settings override that removed the broad traffic restriction also restored both Session and Weekly windows.

After applying the settings workaround below, T3’s unmodified production probe, using the saved settings with no temporary overrides, returned:

Provider status: ready
Authentication: authenticated
Session limits: returned
Weekly limits: returned
Unavailable: none

No model prompt or paid turn was needed. No T3 source changes were made. The banner was observed before the workaround; verification afterward was through the backend probe.

Workaround

Remove CLAUDE_CODE_DISABLE_NONESSENTIAL_TRAFFIC from Claude’s settings. To keep telemetry, error reporting, auto-updates, and feedback disabled, use their individual controls:

{
  "env": {
    "DISABLE_TELEMETRY": "1",
    "DISABLE_ERROR_REPORTING": "1",
    "DISABLE_AUTOUPDATER": "1",
    "DISABLE_FEEDBACK_COMMAND": "1"
  }
}

This removes the broad traffic restriction, so other optional requests may run. Setting the broad flag to "0" does not disable it; Claude treats any non-empty value as enabled. See Claude’s environment-variable documentation.

Impact

Minor bug: subscription limits remain unavailable with a generic warning until the configuration is diagnosed.

Related report

#15364 covers a null limits response being incorrectly classified as unsupported. In the checkout tested here, that response is already classified as probeFailed; the remaining problem is explaining this specific configuration cause.

Same issue on macOS, confirmed via t3 triage.

T3 Code Desktop Nightly 0.1.7-nightly.20261101.4035, macOS 27.0 (Darwin 27.0.0) arm64
Claude Code 2.1.316, Claude Pro, @anthropic-ai/claude-agent-sdk 0.3.276
~/.claude/settings.json → env.CLAUDE_CODE_DISABLE_NONESSENTIAL_TRAFFIC: "1"

Running the same usage_EXPERIMENTAL…({ skipBehaviors: true }) call the T3 probe makes returned {"rate_limits_available": true, "rate_limits": null} in ~4 ms every time, including after 3–8 s delays and with skipBehaviors: false. With the flag removed from the process env, the same call returned five_hour and seven_day windows. A flag-settings override of "0" did not help, consistent with any non-empty value counting as enabled.

The CLI caches a successful read in ~/.claude.json (cachedUsageUtilization) and serves it even while the flag is set. So limits can appear to "work" briefly after any unrestricted read, then return to "Could not read limits" once the cache goes stale. That could confuse anyone verifying a fix or workaround.

The workaround from the issue body (replacing the broad flag with the individual DISABLE_* opt-outs) was applied on this machine.

Triaged with Claude Code (Claude Opus 5.5) via t3 triage.

Another case of the same cause, but this time the flag is not in ~/.claude/settings.json. That makes it much harder to find.

Environment

T3 Code Nightly desktop app 0.1.7-nightly.20261103.4106, local server, same version
macOS 27.0.0, arm64
Claude Code 2.1.317, @anthropic-ai/claude-agent-sdk 0.3.284
Claude Max subscription, authenticated

What is different here

The Claude provider binaryPath points to a wrapper script. The script starts Claude through a corporate gateway launcher. The launcher spawns Claude with this environment:

CLAUDE_CODE_DISABLE_NONESSENTIAL_TRAFFIC=1
DISABLE_TELEMETRY=1
DISABLE_ERROR_REPORTING=1
DISABLE_AUTOUPDATER=1
DISABLE_GROWTHBOOK=1

The user's own settings do not contain the flag. T3 showed only "Claude: Could not read limits." The provider status cache had usageLimits.unavailable.reason: "probeFailed", and all probe spans in server.trace.ndjson exited with Success. Nothing pointed at the environment.

Evidence

I ran the same probe as probeClaudeCapabilities (initializationResult(), then usage_EXPERIMENTAL_MAY_CHANGE_DO_NOT_RELY_ON_THIS_API_YET({ skipBehaviors: true })) outside T3:

Executable	`get_usage` result
wrapper (launcher sets the flag)	`rate_limits_available: true`, `rate_limits: null` (returned in about 2 ms, so no request was made)
plain `claude`	`five_hour` and `seven_day` windows returned
wrapper plus `--settings '{"env":{"CLAUDE_CODE_DISABLE_NONESSENTIAL_TRAFFIC":"0"}}'`	`five_hour` and `seven_day` windows returned

Workaround

A settings env override wins over the inherited process environment. The wrapper now passes "env":{"CLAUDE_CODE_DISABLE_NONESSENTIAL_TRAFFIC":"0"} in its --settings JSON. The individual DISABLE_* flags from the launcher stay set.

Suggestion

This supports the request in this issue. When get_usage returns rate_limits_available: true with rate_limits: null, T3 could check the environment it passes to Claude, including what a wrapper may add. A process-env check alone would miss this case, so the warning could at least name CLAUDE_CODE_DISABLE_NONESSENTIAL_TRAFFIC as a likely cause.

Diagnosed via t3 triage with Claude Code (Claude Opus 5.5).

@krissemicolon

Correction to my earlier comment: the "0" override does not work. It only looked like it worked because of the usage cache that @krissemicolon described above.

What I found

Claude Code 2.1.317 treats any non-empty value of CLAUDE_CODE_DISABLE_NONESSENTIAL_TRAFFIC as enabled. This includes "0", in the process env and in --settings env.
My wrapper set "env":{"CLAUDE_CODE_DISABLE_NONESSENTIAL_TRAFFIC":"0"}. Limits showed while cachedUsageUtilization in ~/.claude.json was fresh. When the cache went stale, T3 showed "Claude: Could not read limits." again.
The T3 update (nightly 4106 → 4119) only happened at the same time. No Claude usage probe code changed between those builds.

Evidence

I ran the same probe as probeClaudeCapabilities outside T3, about 70 s apart, so that each run started with a stale cache. "Live read" means cachedUsageUtilization.fetchedAtMs changed.

Case	Live read
wrapper with settings env `"0"`	no (about 3 ms)
plain `claude` + settings env `"0"`	no
plain `claude` + process env `=1`	no
plain `claude` + `DISABLE_TELEMETRY`, `DISABLE_ERROR_REPORTING`, `DISABLE_AUTOUPDATER`, `DISABLE_GROWTHBOOK`, `DISABLE_FEEDBACK_COMMAND` = `1`	yes
process env `=1` + settings env `""`	yes
wrapper with settings env `""`	yes

Note: if you check a workaround right after any live read, the cached result hides a broken setup. Wait for the cache to go stale, or check that fetchedAtMs changes.

Working workaround

Pass an empty string, not "0":

--settings '{"env":{"CLAUDE_CODE_DISABLE_NONESSENTIAL_TRAFFIC":""}}'

Environment

T3 Code Nightly desktop app 0.1.7-nightly.20261103.4119, local server, same version
macOS 27.0.0, arm64
Claude Code 2.1.317, @anthropic-ai/claude-agent-sdk 0.3.284, Claude Max

This makes the request in this issue more important. The flag has a non-obvious truthiness rule, and the cache hides it. If get_usage returns rate_limits_available: true with rate_limits: null, the warning could name CLAUDE_CODE_DISABLE_NONESSENTIAL_TRAFFIC and say that any non-empty value, also "0", enables it.

Diagnosed via t3 triage with Claude Code (Claude Opus 5.5).

+1 to this

Confirmed on Linux as well, with a newer nightly:

T3 Code desktop: 0.1.8-nightly.20261105.4218
OS: Omarchy 4.0.6 (Arch-based Linux)
Claude Code: 2.1.318

Usage → Limits shows Claude: Could not read limits. The saved ~/.claude/settings.json contains env.CLAUDE_CODE_DISABLE_NONESSENTIAL_TRAFFIC: "1".

Verified through Claude Code's stream-json control protocol, without sending a model prompt:

Send initialize, then get_usage with skip_behaviors: true using the saved settings. Response is successful but contains rate_limits_available: true and rate_limits: null.
Repeat with the temporary CLI override --settings '{"env":{"CLAUDE_CODE_DISABLE_NONESSENTIAL_TRAFFIC":"0"}}': limits remain null.
Repeat with --settings '{"env":{"CLAUDE_CODE_DISABLE_NONESSENTIAL_TRAFFIC":""}}': rate_limits is populated, including five_hour, seven_day, and model_scoped.

A direct authenticated GET to Anthropic's /api/oauth/usage also returned HTTP 200 with limit data, confirming that authentication and the upstream endpoint were working. No credentials or account identifiers are included here.

The temporary override did not modify saved settings or the T3 installation. This corroborates the request for an actionable warning identifying the broad traffic restriction, while respecting the user's setting.

Navigation Menu

Repository navigation

[Bug]: Claude limits warning does not explain when reads are blocked by CLAUDE_CODE_DISABLE_NONESSENTIAL_TRAFFIC #27492

Summary

Area

Steps to reproduce

Expected behavior

Actual behavior

Environment

Investigation and verification

Workaround

Impact

Related report

Environment

What is different here

Evidence

Workaround

Suggestion

What I found

Evidence

Working workaround

Environment

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

[Bug]: Claude limits warning does not explain when reads are blocked by CLAUDE_CODE_DISABLE_NONESSENTIAL_TRAFFIC #27492

Description

Summary

Area

Steps to reproduce

Expected behavior

Actual behavior

Environment

Investigation and verification

Workaround

Impact

Related report

Activity

krissemicolon commented on Nov 1, 2026

mixram commented on Nov 3, 2026

Environment

What is different here

Evidence

Workaround

Suggestion

mixram commented on Nov 3, 2026

What I found

Evidence

Working workaround

Environment

mickroplastics commented on Nov 4, 2026

mauricioliu commented on Nov 7, 2026

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions