claude -p answers 'Login expired' in a fresh CLAUDE_CONFIG_DIR while claude auth status reports loggedIn true

Summary

In a fresh CLAUDE_CONFIG_DIR, claude auth status reports loggedIn: true while claude -p answers "Login expired". The two commands disagree about the same directory, and there is no documented non-interactive way to run a headless session in an isolated configuration directory (for example for plugin audits or CI).

Steps to reproduce

Claude Code 2.1.293, macOS arm64, 2026-10-10.

mkdir -p /tmp/cfg-probe
CLAUDE_CONFIG_DIR=/tmp/cfg-probe claude auth status
CLAUDE_CONFIG_DIR=/tmp/cfg-probe claude -p "say OK"

Observed

claude auth status prints loggedIn: true, authMethod: oauth_token, apiProvider: firstParty, and the configuration directory is the empty probe directory.

claude -p "say OK" prints: Login expired · Run /login to sign in again, or re-authenticate your Anthropic profile and exits without a model call.

I could not determine whether the oauth_token method comes from the environment of the parent shell (the command was run from inside a Claude Code session).

Expected

claude auth status and claude -p agree. If an isolated directory needs its own login, auth status says it is not logged in there. The error message names the non-interactive routes that exist (claude auth login in that directory, or claude setup-token for a long-lived token), so that someone who needs an isolated headless profile knows what to do.

Impact

Plugin and mod audits, benchmarks and CI smoke tests need a clean profile to avoid reading the user's real configuration. With the login bound to the configuration directory and the error pointing only to /login, an automated run cannot be set up without an interactive step per directory, and an agent that tried three isolation setups found no working one.

Related

#81097 (closed): a headless claude -p session under a secondary CLAUDE_CONFIG_DIR login could not attach claude.ai connectors.