How to Configure Codex CLI in Pi Agent and Fix the unsupported_country_region_territory Error

One of the more confusing issues when connecting Codex to Pi Agent is that the error message often points developers in the wrong direction. Many users immediately start modifying provider settings, model parameters, or configuration files. In practice, the problem usually appears much earlier in the authentication flow.

A common example looks like this:

Error: OAuth refresh failed for openai-codex

OpenAI Codex token refresh failed (403):

{
  "error":{
    "code":"unsupported_country_region_territory",
    "message":"Country, region, or territory not supported",
    "param":null,
    "type":"request_forbidden"
  }
}

At first glance, this appears to be a regional access restriction. After tracing the complete login and token lifecycle, the root cause is often related to OAuth token refresh requests rather than model access itself.

This article walks through how Pi Agent integrates with Codex, where authentication failures occur, and how to systematically diagnose the issue.

Understanding How Pi Agent Connects to Codex

Before troubleshooting, it helps to understand the two common ways Pi Agent works with Codex.

Method 1: Using Pi Agent’s Built-in OpenAI Codex Provider

Pi Agent includes native support for OpenAI Codex authentication.

Start Pi Agent:

pi

Open the login menu:

/login

Choose:

ChatGPT Plus/Pro (Codex)

Complete the browser authorization flow.

After authentication succeeds, verify the active provider:

/provider

or:

/models

You should see an entry similar to:

openai-codex

Pi Agent stores authentication information locally:

~/.pi/agent/auth.json

This file contains the tokens used for future authentication and refresh operations.

Method 2: Using a Local Codex CLI Installation

Some users prefer running Codex CLI independently and allowing Pi Agent to interact with that environment.

First, confirm that Codex CLI itself is working correctly.

codex login

Check the authentication status:

codex login status

If this command already returns authentication errors, Pi Agent will typically fail as well because both depend on OpenAI’s OAuth infrastructure.

Why the unsupported_country_region_territory Error Appears

Many developers assume the message indicates a hard regional restriction.

Real-world troubleshooting often reveals a different pattern.

A typical sequence looks like this:

  1. Browser authorization succeeds.
  2. Codex works normally.
  3. Several hours or days pass.
  4. Authentication suddenly fails.
  5. The refresh process returns:
unsupported_country_region_territory

This behavior suggests that the initial login was successful and the failure occurred later during token renewal.

The authentication path generally looks like:

Pi Agent
    ↓
OpenAI OAuth Refresh
    ↓
403 Forbidden

Once the error reaches this stage, changing model settings or provider configurations rarely helps because the failure occurs before model access begins.

The Most Common Cause: OAuth Refresh Requests Bypass the Proxy

One of the most frequent issues involves inconsistent network routing.

The browser authorization request and the OAuth refresh request do not always follow the same path.

The initial login may look like this:

Browser
    ↓
Proxy
    ↓
OpenAI

Authentication succeeds.

Later, when Pi Agent refreshes the token:

Pi Agent
    ↓
Local Network
    ↓
OpenAI

The refresh request bypasses the proxy entirely.

The result:

unsupported_country_region_territory

Although the message references location support, the underlying problem may simply be that the request originates from a different network path than the original authorization.

This behavior is common in OAuth-based tooling and authentication workflows.

How to Verify Whether the Proxy Is Actually Working

Start by inspecting your proxy environment variables.

Linux and macOS

echo $HTTP_PROXY
echo $HTTPS_PROXY
echo $ALL_PROXY

Windows PowerShell

echo $env:HTTP_PROXY
echo $env:HTTPS_PROXY
echo $env:ALL_PROXY

A properly configured environment typically returns values such as:

http://127.0.0.1:7890

or:

socks5://127.0.0.1:7890

Empty results indicate that the current terminal session is not using a proxy.

Next, verify the actual outbound IP address.

curl https://ipinfo.io

Review the response carefully.

If the IP matches the expected proxy endpoint, the proxy is active.

If the response shows your local network address, OAuth refresh traffic may be bypassing the proxy configuration.

Forcing Pi Agent to Use a Proxy

If you are using Clash or a similar proxy tool, explicitly export proxy variables before launching Pi Agent.

export HTTP_PROXY=http://127.0.0.1:7890
export HTTPS_PROXY=http://127.0.0.1:7890
export ALL_PROXY=socks5://127.0.0.1:7890

Restart Pi Agent afterward:

pi

This ensures that the application inherits the required networking configuration from the current shell session.

Checking Whether an Expired Token Is Stored Locally

Another common cause involves stale authentication data.

Inspect the authentication file.

Linux and macOS

cat ~/.pi/agent/auth.json

Windows

type $HOME\.pi\agent\auth.json

If you see content similar to:

{
  "openai-codex": {
    ...
  }
}

Pi Agent already has stored authentication information.

The refresh token may have become invalid.

You can log out directly:

/logout openai-codex

Or remove the local authentication cache:

rm ~/.pi/agent/auth.json

Then reauthenticate:

/login openai-codex

This creates a new OAuth session and refresh token.

A Practical Troubleshooting Workflow

When investigating authentication failures, following a consistent sequence saves time.

Step 1: Verify Codex CLI

codex login status

If this fails, focus on fixing Codex authentication first.

Step 2: Verify Proxy Connectivity

curl https://ipinfo.io

Confirm the outbound IP address.

Step 3: Inspect Stored Authentication Data

cat ~/.pi/agent/auth.json

Check whether previous tokens exist.

Step 4: Reauthenticate

/logout openai-codex
/login openai-codex

Generate a fresh OAuth session.

Following this order usually identifies the root cause quickly.

Most cases fall into one of four categories:

Problem Type Description
Expired OAuth Token Refresh token is no longer valid
Missing Proxy Configuration Environment variables are not configured
OAuth Refresh Bypasses Proxy Login succeeds but refresh requests use a different network path
OpenAI Returns 403 Authentication request is rejected during refresh

The key observation is that these failures occur during authentication. Model configuration, provider settings, and prompt engineering generally have no impact on the outcome.

Quick Checklist

  • [ ] Launch Pi Agent
  • [ ] Verify the active provider
  • [ ] Confirm Codex CLI login status
  • [ ] Check HTTP_PROXY
  • [ ] Check HTTPS_PROXY
  • [ ] Check ALL_PROXY
  • [ ] Verify outbound IP with curl
  • [ ] Inspect auth.json
  • [ ] Remove stale authentication data
  • [ ] Reauthenticate with OpenAI

Frequently Asked Questions

Can Pi Agent use Codex directly?

Yes. Pi Agent includes native support for the OpenAI Codex provider.

Where is the authentication file stored?

By default:

~/.pi/agent/auth.json

Does unsupported_country_region_territory always indicate a regional restriction?

No. It can also occur when OAuth refresh requests fail to use the expected proxy route.

Why does browser login work while Pi Agent fails?

The browser and Pi Agent may be using different network paths.

Codex CLI works but Pi Agent does not. What should I check first?

Verify that Pi Agent inherits the correct proxy environment variables.

What happens if I delete auth.json?

Pi Agent removes the stored OAuth session and requires a new login.

Can changing model parameters fix this error?

Typically no. The failure occurs during authentication, before model access begins.

What is the first command I should run during troubleshooting?

codex login status

This quickly determines whether the authentication layer is functioning correctly.