Your AI Dev Credentials Are the New API Key — And You Are Not Protecting Them

On June 1, 2026, Aikido Security disclosed that a malicious npm package called codexui-android had been silently stealing OpenAI Codex authentication tokens from developers for approximately two months. The package had 29,000+ weekly downloads. It sent the contents of ~/.codex/auth.json — access token, refresh token, ID token, and account ID — to an attacker-controlled server impersonating Sentry [1].

The refresh token does not expire. Every developer who installed that package gave an unknown attacker permanent silent access to their OpenAI Codex account until they manually revoke it.

``takeaways - codexui-android (29K+ weekly downloads) exfiltrated ~/.codex/auth.json to sentry.anyclaw[.]store [1]. - Refresh tokens stolen in the attack do not expire — impersonation persists until manually revoked [1]. - Two Android apps by publisher "BrutalStrike" delivered the same payload (50K+ and 10K+ installs) [1]. - Immediate action: revoke Codex tokens at platform.openai.com now. Do not wait to investigate first. ``

What Was Stolen and Why It Matters

The credential file targeted — ~/.codex/auth.json — is created automatically when a developer authenticates with the Codex CLI. Most developers are unaware it exists. It contains four fields [1]:

The refresh token is the critical failure. In standard OAuth flows, refresh tokens are the long-lived credential that allows a client to request new access tokens without re-authenticating. Holding a valid refresh token is equivalent to holding a password that never changes.

An attacker with your refresh token can: - Generate new access tokens indefinitely - Access Codex and associated OpenAI services - Incur API usage billed to your account - Access any data or integrations your Codex session can reach

This is not a temporary exposure. If you installed codexui-android and have not revoked your tokens, you are still compromised right now.

How the Attack Worked

The attack followed a deliberate multi-stage pattern designed to evade detection [1]:

Stage 1 — Establish legitimacy. The first npm upload (version 0.1.72) happened on April 10, 2026 with no malicious code. The package presented a clean GitHub repository with plausible development history.

Stage 2 — Register attacker infrastructure. The domain anyclaw[.]store was registered on April 12, 2026 — two days after the npm upload. The subdomain sentry.anyclaw[.]store impersonates the legitimate Sentry error monitoring service, a tool common in developer environments. An HTTP request to a Sentry-looking endpoint from a developer tool raises no alarms.

Stage 3 — Inject the payload. Exfiltration code appeared in version 0.1.82. The package reads ~/.codex/auth.json and sends its contents to the attacker's server on installation or execution.

Stage 4 — Expand the surface. The same payload was distributed through two Android apps published under the name "BrutalStrike": - OpenClaw Codex Claude AI Agent (package: gptos.intelligence.assistant): 50,000+ installs - Codex (package: codex.app): 10,000+ installs

The Android apps ran the exfiltration within a PRoot sandbox, suggesting the attacker understood the mobile execution environment [1].

The gap between first upload (April 10) and public disclosure (June 1) is approximately 52 days. During that window, every install of versions 0.1.82+ sent credentials to the attacker.

If You Installed This Package: What to Do Now

Do not investigate first. Revoke first.

Step 1 — Revoke tokens immediately. Log into platform.openai.com, navigate to account management, and revoke active sessions and tokens. This invalidates the refresh token and ends the attacker's persistent access.

Step 2 — Delete the credential file. ``bash rm ~/.codex/auth.json ``

Step 3 — Re-authenticate from a clean device. Do not re-authenticate on the same machine until you have audited what else is installed. The exfiltration code ran at install time; verify the codexui-android package is removed.

Step 4 — Audit your npm history. ``bash npm ls --global | grep codex cat ~/.npm/_logs/*.log | grep codexui ``

Step 5 — Review account activity. Check platform.openai.com for API usage patterns inconsistent with your own activity. Unusual usage spikes since mid-April 2026 may indicate the attacker was using your credentials.

Step 6 — Report to OpenAI security. If you confirm exposure, report via OpenAI's security disclosure channel. This helps them track the scope of account compromise.

The Broader Problem: AI Tooling Creates Unprotected Credential Files

The Codex attack is a preview of a wider threat pattern. Every AI developer tool that authenticates via OAuth or API key writes a credential file to your home directory. Most developers treat these as transparent plumbing — they exist, they work, and they are never thought about again.

Here is what that looks like across the tools many developers now have installed:

None of these files have the cultural protection that .env files have acquired over the past decade. Developers are trained to .gitignore and never commit .env. They are not trained to think about ~/.codex/auth.json.

The attacker who built codexui-android understood this gap. Their payload targeted a specific path that: 1. Every Codex CLI user has 2. Almost no one monitors 3. Contains long-lived credentials 4. Is readable by any process running as that user

This is exactly the pattern that made API key theft via environment variable leaks so effective in the 2019–2022 period, before .env hygiene became normalized. We are at the same stage with AI tool credential files in 2026.

What Good Credential Hygiene Looks Like for AI Tooling

Treat auth files as secrets, not config. Add AI tool credential paths to your .gitignore globally: ``bash # ~/.gitignore_global .codex/ .claude/ .gemini/ .config/gh/ ``

Run git config --global core.excludesfile ~/.gitignore_global if you have not already.

Restrict file permissions. ``bash chmod 600 ~/.codex/auth.json chmod 700 ~/.codex/ ``

Only your user account should be able to read the file. This does not protect against processes running as your user, but it eliminates world-readable exposure.

Audit installed npm packages before running them. For any package touching AI tooling credentials, read the source before installing. npx makes this easy to skip; do not skip it for packages in the AI tooling namespace: ``bash npm pack <package-name> --dry-run # or inspect the unpacked tarball ``

Enable npm audit as a CI gate. If you maintain a repo that depends on AI tooling packages, add npm audit as a step. It will not catch zero-day malicious packages, but it catches known-vulnerable dependency chains.

Use short-lived tokens where the tool supports it. OpenAI's platform allows API key rotation. Prefer short-lived API keys scoped to specific use cases over long-lived OAuth sessions for automated workflows. Reserve OAuth flows for interactive CLI use.

Monitor for unexpected API usage. Set up usage alerts in platform.openai.com. An unexpected spike in API calls — especially outside your working hours or from unusual IPs — is the signal you need to catch a compromised token before it causes significant damage.

What This Signals for AI Developer Security

The codexui-android attack is not sophisticated in its execution — it is a credential-harvesting script targeting a predictable file path. What makes it notable is the target selection: the attacker correctly identified that AI developer tooling credential files are high-value, poorly protected, and systematically ignored by the security posture most developers have built around their environments.

This is the first publicly disclosed attack targeting an AI CLI tool's credential file at scale. It will not be the last.

The security community's response to API key leaks in the early cloud era was to normalize .env files, build pre-commit hooks for secret scanning, and make credential-in-code a CI failure. That took approximately three years after the first major incidents.

The AI developer tooling ecosystem is at day one of that cycle. The ~/.codex/auth.json file today is what a hardcoded AWS key in a GitHub repo was in 2018. The tooling to detect and prevent these leaks does not yet exist at scale. The cultural norms are not yet established.

That window is exactly when attackers operate. Build the hygiene now, before the norm exists, and you will not be in the window when the next attacker targets ~/.claude/auth.json or ~/.gemini/credentials.

The Broader Wave: Codex Is One Target Among Many

The codexui-android disclosure landed the same week as three other confirmed supply-chain campaigns converging on developer machines. These are not isolated incidents — they represent a coordinated shift in attacker strategy.

TrapDoor (May 2026) distributed 34+ malicious packages across npm, PyPI, and Crates.io targeting crypto, DeFi, and AI developers. What makes it distinct: attackers injected .cursorrules and CLAUDE.md files designed to poison AI coding assistants. A developer working in a compromised repository would have their AI assistant — Cursor, Claude Code — silently instructed to conduct "security scans" that exfiltrate secrets to attacker infrastructure. "TrapDoor targets developers in crypto, DeFi, Solana, and AI communities. The malicious packages are designed to steal developer secrets, crypto wallets, SSH keys, cloud credentials, browser data, and environment variables." — Socket (The Hacker News, 2026-05-27)

Shai-Hulud / Mini Shai-Hulud is a self-propagating npm worm from the TeamPCP threat actor, now on its seventh confirmed wave since March 2026. It has hit Trivy, LiteLLM, Bitwarden CLI, TanStack, and the Nx Console VS Code extension. The Nx Console attack specifically targeted ~/.claude/settings.json — the Claude Code config file, not Codex. The worm spreads by compromising npm publish tokens and re-releasing packages under legitimate namespaces, making it structurally self-amplifying. Immediate remediation requires rotating all CI secrets: GitHub tokens, npm tokens, NX_CLOUD_ACCESS_TOKEN, and cloud provider credentials. (StepSecurity, 2026-06-04)

Red Hat npm supply chain (June 2, 2026): Wiz researchers documented attackers compromising GitHub Actions workflows to forge valid SLSA Build Level 3 provenance attestations for malicious releases in the @redhat-cloud-services namespace. The attack vector: the compromised workflow requested GitHub OIDC identity tokens and published packages with legitimate-looking provenance metadata. Valid SLSA attestation is no longer a trust signal when the build pipeline itself is the attack surface. (CSO Online, 2026-06-02)

BadHost / CVE-2026-48710 (May 2026): A single-character HTTP Host header injection bypasses path-based authorization in Starlette, the routing core of FastAPI — and by extension vLLM, LiteLLM, most OpenAI-shim proxies, and the majority of MCP servers. This network-level attack converges on the same credential stores that supply-chain attacks target via malicious packages. Patch your Starlette version and audit any MCP server accepting external HTTP traffic. (Ars Technica, 2026-05-29)

The common thread: "A single compromised workstation can quietly become an entry point into CI/CD pipelines and build infrastructure. That's not credential theft. That's an initial access operation." — Sakshi Grover, IDC Asia Pacific (CSO Online, 2026-05-27). Developer machines running AI tooling are now the highest-value initial access target in the modern software supply chain, and the campaigns are converging simultaneously.

If you want to build secure AI agent systems from the ground up — not just patch the last breach — the [AI Agent Security for Developers](https://academy.kspl.tech/courses/ai-agent-security-for-developers) course covers exactly this. Chapter 4 covers credential isolation patterns so your agents never hold long-lived plaintext tokens. Chapter 5 covers CI/CD hardening so a compromised package publisher cannot forge valid provenance for your pipeline.

See also: ai-coding-agent-supply-chain-threat-atlas-2026 for the broader threat landscape across AI developer tooling.

See also: mcp-server-registry-security for supply chain risks specific to MCP server dependencies.