Claude Code does not handle new OAuth after archiving workspace

[alin-ap]

Environment

• Platform (select one):
  • Anthropic API
  • AWS Bedrock
  • Google Vertex AI
  • Other:
• Claude CLI version: v0.3.6
• Operating System: macOS 14.3
• Terminal: Terminal App (zsh)

Bug Description

I've successfully completed OAuth authentication for Claude Code CLI, and the Anthropic website confirmed my setup with the message:

"You’re all set up for Claude Code. You can now close this window."

However, when I attempt to use the Claude Code CLI (claude), it immediately returns the following error:

API Error: 403 {"error":{"type":"forbidden","message":"Request not allowed"}}

My Anthropic console shows newly generated API keys in the Claude Code workspace, but the CLI still cannot authenticate successfully.

Steps to Reproduce

1. Install Claude Code CLI globally via npm (npm install -g @anthropic-ai/claude-code)
2. Run the OAuth authentication (claude auth login)
3. Complete OAuth successfully (confirmed by webpage)
4. Run claude command in the terminal
5. Encounter the 403 forbidden error above.

Expected Behavior

Claude Code CLI should authenticate successfully after OAuth, and I should be able to interact normally with the CLI.

Actual Behavior

Claude Code CLI immediately returns a 403 forbidden error ("Request not allowed") every time it is launched.

Additional Context

• My Anthropic account billing is active, with sufficient funds.
• Network proxy and connectivity have been verified as working correctly.
• My Anthropic account email is bobbyding.dy@gmail.com.

Additionally, I observed unexpected behavior in the Anthropic API key management page:

• The API keys associated with Claude Code workspace never show as successfully created (they remain stuck in a pending state without workspace details).
• When attempting to delete these seemingly unsuccessful keys, I consistently receive a "Not found" error, and the keys remain undeleted.

This might indicate a backend issue on Anthropic’s side causing the keys to remain unrecognized or improperly provisioned.

Screenshots:

1. API keys stuck without workspace information:

2. Error ("Not found") when attempting to delete these keys:

---

[alin-ap]

UPDATE (Potential Root Cause Identified)

I believe I have identified the root cause of this issue:

When Claude Code CLI first completed the OAuth authentication, it automatically created a default workspace for storing API keys. However, I mistakenly archived this default workspace. As a result, subsequent OAuth attempts cannot successfully create or associate new API keys.

This explains why the newly created keys remain stuck without workspace details and why attempting to delete these keys results in a "Not found" error.

[alin-ap]

Sorry why close this issue ?

[wolffiex]

seems like this was an issue with auth against a closed workspace? perhaps I misunderstood. if you want to reopen, please explain the repro steps, what you expected to happen, and what actually happened

[alin-ap]

Repro Steps:

1. I initially completed OAuth authentication for Claude Code CLI. Claude Code automatically created a default workspace named "Claude Code".
2. I mistakenly archived this workspace from the Anthropic web console.
3. After archiving, I tried authenticating again. OAuth appears to succeed, and new API keys seem to be created successfully in the web UI.

Expected behavior:

Claude Code CLI successfully authenticates using these newly created API keys, and I can use the CLI normally.

Actual behavior:

Although new API keys appear in the web console, they are not functional. Claude Code CLI consistently returns:

API Error: 403 {"error":{"type":"forbidden","message":"Request not allowed"}}

Additionally, these new API keys in the web UI show no workspace details, and attempting to delete them results in a "Not found" error.

Additional Context:

I strongly suspect archiving the default workspace caused Claude Code CLI to lose reference to its necessary workspace environment, resulting in continuous authentication failures (403 errors).

Could you please reopen and investigate this scenario? Thanks!

[williamlee1982]

same issue here, always get API Error: 403 {"error":{"type":"forbidden","message":"Request not allowed"}}

[ameame-yzq]

I create my api-key successfully,but i get the same issue.

I also check my ip position, it is available.

[Q0k0LaTe]

me 2, did all the api works and returned 403.

[ameame-yzq]

I create my api-key successfully,but i get the same issue.

I also check my ip position, it is available.

I think I find how to handle it. Here is my solution:

Resolving Claude Code 403 Forbidden Error with a Local Proxy

This guide outlines the steps to resolve the 403 Forbidden: Request not allowed error when using the claude CLI tool (or Claude Code integrations like in Cursor) with a local proxy server (e.g., Clash, V2Ray, Surge) on macOS with Zsh.

The primary issue seems to be related to how the claude tool handles the ALL_PROXY environment variable, especially when set to a SOCKS5 proxy. The solution involves ensuring that only HTTP_PROXY and HTTPS_PROXY are set to your local HTTP proxy address and that ALL_PROXY is unset.

Prerequisites

• You have a local proxy client running and know its HTTP proxy address and port (e.g., http://127.0.0.1:7897).
• You are using Zsh as your shell (common on macOS). If using Bash or another shell, adapt the configuration file path accordingly (e.g., ~/.bashrc or ~/.bash_profile).

Steps to Resolve

1. Modify Your Shell Configuration File (~/.zshrc)

The most reliable way to configure the proxy for your terminal sessions is by setting the environment variables in your shell's startup file.

1. Open your ~/.zshrc file in a text editor. You can use a terminal editor like nano or vim, or a graphical editor:

   nano ~/.zshrc
   # Or, for example, with VS Code:
   # code ~/.zshrc

2. Add or modify the proxy export lines. Find any existing lines that set http_proxy, https_proxy, or all_proxy (case-insensitive). It's best to remove or comment out old conflicting settings. Add the following lines, preferably towards the end of the file:

   # Proxy settings for Claude Code and other tools
   export HTTP_PROXY="http://127.0.0.1:7897"
   export HTTPS_PROXY="http://127.0.0.1:7897"
   unset ALL_PROXY # Ensure ALL_PROXY is not set, as it can cause issues with Claude CLI

   • Replace http://127.0.0.1:7897 with the actual HTTP proxy address and port provided by your local proxy client.
   • Using uppercase HTTP_PROXY and HTTPS_PROXY is recommended for broader compatibility.
   • Explicitly unsetting ALL_PROXY helps prevent conflicts.

3. Save the file and exit the text editor. (For nano: Ctrl+X, then Y, then Enter).

4. Apply the changes. For the changes to take effect, you either need to:

   • Close your current terminal window and open a new one.
   • Or, source the configuration file in your current terminal session:

     source ~/.zshrc

2. (Optional but Recommended) Configure claude CLI Settings File

The claude CLI tool also has its own settings file at ~/.claude/settings.json. While it should respect system environment variables, ensuring its internal configuration is consistent can prevent issues, especially for integrations that might read this file directly.

1. Open or create the ~/.claude/settings.json file:

   nano ~/.claude/settings.json

2. Ensure the content is as follows:

   {
     "env": {
       "HTTP_PROXY": "http://127.0.0.1:7897",
       "HTTPS_PROXY": "http://127.0.0.1:7897"
     }
   }

   • Replace http://127.0.0.1:7897 with your actual proxy address.
   • Make sure there is no ALL_PROXY entry in this JSON file.

3. Save the file and exit.

This can help identify if it's still attempting a direct connection or failing at a specific stage of proxy negotiation.

[forbidden-game]

I create my api-key successfully,but i get the same issue.

I also check my ip position, it is available.

I think I find how to handle it. Here is my solution:

Resolving Claude Code 403 Forbidden Error with a Local Proxy

This guide outlines the steps to resolve the 403 Forbidden: Request not allowed error when using the claude CLI tool (or Claude Code integrations like in Cursor) with a local proxy server (e.g., Clash, V2Ray, Surge) on macOS with Zsh.

The primary issue seems to be related to how the claude tool handles the ALL_PROXY environment variable, especially when set to a SOCKS5 proxy. The solution involves ensuring that only HTTP_PROXY and HTTPS_PROXY are set to your local HTTP proxy address and that ALL_PROXY is unset.

Prerequisites

• You have a local proxy client running and know its HTTP proxy address and port (e.g., http://127.0.0.1:7897).
• You are using Zsh as your shell (common on macOS). If using Bash or another shell, adapt the configuration file path accordingly (e.g., ~/.bashrc or ~/.bash_profile).

Steps to Resolve

1. Modify Your Shell Configuration File (~/.zshrc)

The most reliable way to configure the proxy for your terminal sessions is by setting the environment variables in your shell's startup file.

1. Open your ~/.zshrc file in a text editor. You can use a terminal editor like nano or vim, or a graphical editor:
   nano ~/.zshrc

   Or, for example, with VS Code:

   code ~/.zshrc

2. Add or modify the proxy export lines. Find any existing lines that set http_proxy, https_proxy, or all_proxy (case-insensitive). It's best to remove or comment out old conflicting settings. Add the following lines, preferably towards the end of the file:

   Proxy settings for Claude Code and other tools

   export HTTP_PROXY="http://127.0.0.1:7897"
   export HTTPS_PROXY="http://127.0.0.1:7897"
   unset ALL_PROXY # Ensure ALL_PROXY is not set, as it can cause issues with Claude CLI

   • Replace http://127.0.0.1:7897 with the actual HTTP proxy address and port provided by your local proxy client.
   • Using uppercase HTTP_PROXY and HTTPS_PROXY is recommended for broader compatibility.
   • Explicitly unsetting ALL_PROXY helps prevent conflicts.

3. Save the file and exit the text editor. (For nano: Ctrl+X, then Y, then Enter).

4. Apply the changes. For the changes to take effect, you either need to:

   • Close your current terminal window and open a new one.
   • Or, source the configuration file in your current terminal session:
     source ~/.zshrc

2. (Optional but Recommended) Configure claude CLI Settings File

The claude CLI tool also has its own settings file at ~/.claude/settings.json. While it should respect system environment variables, ensuring its internal configuration is consistent can prevent issues, especially for integrations that might read this file directly.

1. Open or create the ~/.claude/settings.json file:
   nano ~/.claude/settings.json

2. Ensure the content is as follows:
   {
   "env": {
   "HTTP_PROXY": "http://127.0.0.1:7897",
   "HTTPS_PROXY": "http://127.0.0.1:7897"
   }
   }

   • Replace http://127.0.0.1:7897 with your actual proxy address.
   • Make sure there is no ALL_PROXY entry in this JSON file.

3. Save the file and exit.

This can help identify if it's still attempting a direct connection or failing at a specific stage of proxy negotiation.

Perfectly solved!~

[alexkrauss]

People are starting to post strange workarounds here, but I think this misses the root cause:

• If the "Claude Code" workspace is archived, then either
  • a) the oauth step should fail completely with a clear error, or
  • b) the tokens created in this step should actually work.

Currently, we seem to be in the situation where the tokens are created successfully, but then do not work. This is very confusing, and people who archived "Claude Code" cannot even recover from this, since there is no "un-archive" operation.

In our organization, we actually want to have our users in multiple, different workspaces for cost transparency reasons. So ideally, in the login flow, users would be able to choose a workspace from a list of workspaces they have access to. The token would then be created in that workspace. This would be a logical flow and allow us to archive the generic "Claude Code" workspace, which does not make sens for the organization.

So I propose to reopen this to at least fix the confusing situation where API keys get created that don't work. @wolffiex