Malicious npm builds of codexui-android steal Codex tokens

At a glance

What this is: This is a supply-chain credential theft case where published npm builds of codexui-android exfiltrated Codex authentication data from local developer environments.

Why it matters: It matters because developer tooling can become an identity compromise path when local auth files, refresh tokens, and runtime package updates are trusted without artifact verification.

👉 Read Corgea's analysis of codexui-android token theft and runtime npm risk

Context

The core problem is not just malicious code in a package, but the trust gap between source repositories and the exact artifacts that are actually installed. In this case, a legitimate-looking npm package became the delivery mechanism for token theft because the published build did not match the GitHub source tree, and the install path reached into local Codex authentication state. That is a direct identity and secrets governance issue, not only a software supply chain issue.

For IAM and NHI practitioners, this sits at the boundary between developer identity, secrets exposure, and agentic workflow access. A stolen refresh token or cached auth object can preserve access well beyond the original session, which means local developer tools must be treated as part of the credential attack surface. This is typical of the broader pattern where runtime dependency trust is weaker than source-code review suggests.

Key questions

Q: What breaks when an AI developer tool installs unpinned packages at runtime?

A: The main failure is loss of deterministic trust. If a tool pulls @latest or other unpinned dependencies at startup, security teams can no longer reliably predict which code will execute or which secrets that code can access. That creates a supply chain window where artifact integrity, not just source review, becomes the deciding control.

Q: Why do local AI auth files create a high-value identity risk?

A: Because they often contain reusable credentials, especially refresh tokens, that outlive a single session and can be abused from another host. Once those files are exposed, the attacker may not need a password or interactive login at all, only the stolen token material and a place to use it.

Q: How do security teams know whether a package has crossed from software risk into secrets risk?

A: The signal is whether the package can read local credential caches, environment variables, or workspace auth state before the user notices. If a dependency can access token stores, code repos, or session files, it has crossed into secrets governance territory and should be treated as part of the identity attack surface.

Q: What should teams do immediately after discovering token exfiltration from a developer tool?

A: Contain the host, revoke the affected sessions from a clean device, and rotate any credentials or workspace entitlements that may have been accessible through the stolen token. Then review package-manager caches, app sandboxes, and telemetry for the same artifact lineage so the compromise does not persist through a second install.

Technical breakdown

Why published package artifacts matter more than repository source

npm supply-chain attacks often succeed because defenders inspect the public repository but install the registry tarball. If the published artifact includes extra code, the attacker controls the runtime before the application’s own logic starts. That means package integrity, provenance, and diffing the packed artifact against source all matter. In this case, the malicious code executed at module load, before normal CLI behavior, which is exactly where many review processes are weakest.

Practical implication: verify the installed tarball and signature chain, not just the GitHub repository.

How local auth file theft turns a developer tool into identity compromise

The package targeted ~/.codex/auth.json or CODEX_HOME/auth.json, which are local credential caches rather than harmless config files. Those files can contain access tokens, refresh tokens, and account metadata. Refresh tokens are the most damaging because they can outlive a single access token and preserve access from a different device. In identity terms, this is credential harvesting from a trusted workstation or sandbox, followed by durable account abuse.

Practical implication: treat local AI tool auth caches as secrets that require the same controls as API keys and passwords.

Why runtime dependency trust is a governance problem for AI tooling

AI developer tools increasingly bootstrap packages at runtime, sometimes with @latest resolution, which makes the first execution moment a hidden supply-chain decision point. That shifts security from static app review to ongoing artifact trust, version pinning, and network inspection. When the tool also interfaces with code, workspaces, or agentic workflows, the blast radius extends beyond the host to source code access and delegated actions.

Practical implication: require version pinning, allowlisted registries, and runtime monitoring for every AI-enabled developer workflow.

Threat narrative

Attacker objective: The attacker’s objective is to steal Codex authentication tokens, preserve access through refresh tokens, and use that access to reach code or agentic workflow resources.

1. Entry occurred when users or apps installed codexui-android from the npm registry, including runtime bootstrap paths that pulled the package at first run. Credential access followed when the package read local Codex authentication files from developer machines or sandboxed Android environments. Impact came when the token object was exfiltrated to an attacker-controlled endpoint, creating account takeover and persistent access risk.

Breaches seen in the wild

• GitHub Dependabot Breach — GitHub Dependabot tokens stolen and abused to push malicious commits to repositories.
• Shai Hulud npm malware campaign — Shai Hulud campaign: npm malware exposed secrets on GitHub.

Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Artifact-level trust is now a first-class identity control. This case shows that source review alone is not enough when the installed package can differ from the repository. For AI-enabled developer tools, the artifact is the executable trust boundary, and that boundary can expose secrets as quickly as any phishing page. Practitioners should treat npm tarballs, runtime bootstraps, and package-manager caches as governed identity and secret assets.

Local AI auth caches are effectively high-value secrets stores. The package did not need to break cryptography or defeat a vault. It only needed access to a locally cached auth file with refresh capability. That makes developer laptops, sandboxes, and app-private runtimes part of the credential estate, which is exactly where traditional IAM and PAM oversight is weakest. The right mental model is not endpoint hygiene alone, but secrets lifecycle control for developer identity.

Runtime @latest installation creates unmanaged access drift. When tools pull new builds at first execution, the security team loses deterministic control over what code is allowed to run. That is a form of supply chain drift that compounds identity risk because the tool can inherit the user’s entitlements and immediately exfiltrate them. The field needs to treat dynamic package resolution as a governance failure mode, not a convenience feature.

Codex token theft is a Non-Human Identity problem as much as a developer security problem. The stolen object is not just a login artifact. It is a machine-usable credential that can be reused by software, sustain access across sessions, and interact with code or workspace permissions without a person present. That makes lifecycle control, token invalidation, and workload-bound authentication central to the response, not optional hardening.

From our research:

• 24,008 unique secrets were exposed in MCP configuration files in 2025 alone, the protocol's first year of widespread adoption, according to The State of Secrets Sprawl 2026.
• From our research: 64% of valid secrets leaked in 2022 are still valid and exploitable today, according to The State of Secrets Sprawl 2026.
• From our research: Track exposed developer tooling and token handling with The 52 NHI breaches Report when you need breach-pattern context for persistence and reuse.

What this signals

Secrets governance is expanding from repositories into runtime tooling. The practical lesson is that package managers, app-private sandboxes, and AI assistants now belong in the same control plane as code scanning and vault monitoring. The trust boundary is no longer where the repository ends, because the runtime install path can reach directly into local auth state and preserve access after the original session. Practitioners should align this control problem with guidance in the OWASP Agentic AI Top 10.

Credential exposure in AI toolchains behaves like a Non-Human Identity failure mode. A locally cached auth object can be reused by software, not just a person, which means traditional password-reset thinking is too narrow. The program signal to watch is whether developer tools can access reusable tokens outside a governed lifecycle. Once they can, revocation latency becomes the real risk variable, not discovery alone.

The next control gap is not detection volume but recovery speed. If teams cannot invalidate tokens, clear runtime caches, and re-establish trusted provenance quickly, the same compromise can reappear through a clean-looking reinstall or a different sandbox. That is why AI developer tooling needs lifecycle controls that span device trust, token issuance, and package provenance at once.

For practitioners

• Audit runtime-installed AI tooling Inventory any developer tools or Android sandboxes that resolve codexui-android@latest or similar packages at startup, then pin versions and restrict allowed registries for those workflows.
• Revoke exposed Codex sessions Assume ~/.codex/auth.json exposure equals credential compromise, revoke Codex and OpenAI sessions from a trusted clean machine, and invalidate refresh tokens rather than only uninstalling the app.
• Inspect artifact provenance before execution Compare packed npm artifacts against source, check install hashes, and require provenance controls for any package that can access developer auth state or code repositories.
• Search for endpoint exfiltration indicators Look for sentry.anyclaw.store, /startlog, and codexui versioned user agents in network telemetry, then correlate those hits with machines that held Codex auth material.
• Treat local auth files as managed secrets Move AI tool credentials into a controlled lifecycle process that includes rotation, revocation, and host-level exposure monitoring for ~/.codex/auth.json and similar caches.

Key takeaways

• This case shows that a legitimate npm package can become a credential theft path when the published artifact is more privileged than the source tree.
• Local AI auth files are part of the identity estate because refresh tokens can preserve access long after the initial compromise.
• The practical control response is provenance, version pinning, and rapid token revocation, not just uninstalling the affected app.

Key terms

• Artifact-Level Trust: Artifact-level trust is the decision to trust the exact package, binary, or container that runs, not just the repository that claims to publish it. In supply chain security, the installed artifact is the real execution boundary, so provenance, hashes, and signature checks matter as much as source code review.
• Refresh Token: A longer-lived credential that can mint new access tokens without forcing the user to authenticate again. Because refresh tokens can preserve access for extended periods, they are a major governance concern when malicious or over-scoped applications are granted consent.
• Runtime Drift: Runtime drift is the gap between an AI agent’s approved authority and its actual behaviour as conditions change. It appears when the agent adapts to new context, new integrations, or new instructions and begins acting outside the scope that governance originally defined.
• Local Auth Cache: A local auth cache is a file or storage location on an endpoint that keeps tokens, session state, or login metadata for later reuse. These caches are convenient for users but dangerous when unmanaged, because compromise of the host can become compromise of the identity behind the tool.

What's in the full analysis

Corgea's full analysis covers the operational detail this post intentionally leaves for the source:

• Exact npm package timeline and published version history for codexui-android
• Code-level excerpts showing where the malicious payload executes before normal CLI logic
• Indicator details for sentry.anyclaw.store, /startlog, and versioned user-agent telemetry
• Remediation guidance for revocation, cache cleanup, and Android app-private sandboxes

👉 Corgea's full post covers the package timeline, token theft path, and triage indicators.

Deepen your knowledge

NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, machine identity security, secrets management, and identity lifecycle control. It helps practitioners build the governance habits needed when credentials, tokens, and software delivery overlap.