Configure proxy for ccstatusline?

[xuanswe]

Hi,

I want to show block reset timer, session usage, weekly reset timer and weekly usage.

My container is running via a proxy and allowed these domains: anthropic.com, claude.com, claude.ai.

If I run claude without proxy, everything works.

The block reset timer works, but other 3 cannot pass the proxy and showing "API Error".

Do you know what differences are between block reset timer and others? Which domains do the others use to request the information?
Do you have any tricks to make it work?

Thanks!

[sirmalloc]

@xuanswe Thanks for the detailed report. I traced this behavior and the difference is expected based on how each widget gets its data.

Block Reset Timer works behind your proxy because it has a local fallback path.
If the usage API is unavailable, it can still compute the current 5-hour window from local Claude transcript/cache data, so it can continue rendering.

The other three widgets do not have that fallback:

• Session Usage
• Weekly Usage
• Weekly Reset Timer

Those three rely on a live API call to:
https://api.anthropic.com/api/oauth/usage

So if that request fails, they show [API Error].

The key proxy requirement is not only domain allowlisting, but header preservation.
That request must pass through with these headers intact:

• Authorization: Bearer <token>
• anthropic-beta: oauth-2025-04-20

If either header is stripped, rewritten, or blocked, the request will fail (auth/beta contract failure), and ccstatusline will surface it as API Error (or Parse Error in some cases).

What to check in your proxy:

1. Allow outbound HTTPS to api.anthropic.com (exact host/FQDN).
2. Forward Authorization unchanged (including Bearer prefix).
3. Forward anthropic-beta unchanged (some proxies drop non-standard headers by default).
4. If TLS inspection is enabled, confirm both headers are still forwarded after decryption/re-encryption.
5. Confirm the API response is HTTP 200 through the proxy path.

So the short answer: Block Reset Timer survives because it can run locally; the other three require a successful proxied call to api.anthropic.com with both required headers preserved.

[xuanswe]

I asked Claude Code and it says:

Root Cause

  ccstatusline fetches usage data by calling api.anthropic.com/api/oauth/usage using Node.js's built-in https.request() (via Bun's node:https compatibility layer):

  // src/utils/usage-fetch.ts (line ~57853 in ccstatusline.js)
  var https = __require("https");
  // ...
  const request2 = https.request({
      hostname: "api.anthropic.com",
      path: "/api/oauth/usage",
      ...

  The problem: Bun's node:https compatibility module does not automatically route requests through HTTPS_PROXY/http_proxy environment variables. Only Bun's native fetch() honors those env vars.

What do you think about AI's idea? Could Claude Code's analysis be right here?

[xuanswe]

My settings:

  "statusLine": {
    "type": "command",
    "command": "bunx -y ccstatusline@latest"
  },

[sirmalloc]

Are you setting an HTTPS_PROXY variable before launching claude code? We can't used fetch because we target node 14 during the build process, but I can make https.request honor the proxy if set.

[sirmalloc]

@xuanswe I've published version 2.2.2 that allows the usage requeste to use the HTTPS_PROXY environment variable to proxy the request. Please let me know if this fixes your issues.

[xuanswe]

Are you setting an HTTPS_PROXY variable before launching claude code? We can't used fetch because we target node 14 during the build process, but I can make https.request honor the proxy if set.

Yes, I configure proxy via standard env vars: http_proxy, https_proxy, HTTP_PROXY and HTTPS_PROXY.

@xuanswe I've published version 2.2.2 that allows the usage requeste to use the HTTPS_PROXY environment variable to proxy the request. Please let me know if this fixes your issues.

Nice, I tested and it works now. Thank you a lot!

  "statusLine": {
    "type": "command",
    "command": "bunx -y ccstatusline@2.2.2"
  },