Claude Code does not handle new OAuth after archiving workspace

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.

Sorry why close this issue ?

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

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!

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

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

!Image

I also check my ip position, it is available.

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

I create my api-key successfully,but i get the same issue. !Image I also check my ip position, it is available.

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

!Image

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:

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

1. 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:

``bash
# 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.

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

1. 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:

``bash
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:

``bash
nano ~/.claude/settings.json
``

1. Ensure the content is as follows:

``json
{
"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.

1. 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.

> I create my api-key successfully,but i get the same issue. > !Image > I also check my ip position, it is available. I think I find how to handle it. Here is my solution: !Image # 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!~

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

I found one simple way. when your claude get "OAuth token has expired" just type /login will refresh the token.

@ameame-yzq You the god!! Thank you!!!

@ameame-yzq
Finally resolved! Thank you!!

@ameame-yzq
Thank you!!

This issue has been automatically locked since it was closed and has not had any activity for 7 days. If you're experiencing a similar issue, please file a new issue and reference this one if it's relevant.