Malicious npm builds of codexui-android steal Codex tokens

At a glance

What this is: Published npm builds of codexui-android were found to read local Codex authentication files and send token objects to an attacker-controlled endpoint hidden as telemetry.

Why it matters: This matters because developer tooling can turn a trusted install path into credential theft, so teams need to verify artifacts, not just source repositories, when local auth state is in scope.

Context

codexui-android is a supply-chain risk because the package behaves like a legitimate developer tool while embedding code that is only visible in the published npm artifact. In practical terms, the security problem is not just package reputation, but whether the install-time binary matches the reviewed source and whether it can reach sensitive local auth state.

The Codex auth file is effectively a secret-bearing credential store, so any tool that can read it becomes part of the identity perimeter. This is a genuine NHI and developer-identity issue because the exposed material includes tokens that can sustain access beyond a single session.

The pattern is typical of modern build and distribution abuse: the repository can look clean while the registry artifact carries the malicious payload. That makes package provenance, runtime trust, and credential handling inseparable for teams shipping or running developer tooling.

Key questions

Q: What breaks when an npm package can read local AI auth files at startup?

A: The boundary between application startup and credential theft disappears. If a package can read local auth files before normal execution, then token protection depends on artifact integrity, file permissions, and revocation discipline rather than on repository review alone. That is a governance failure because the install path becomes part of the identity attack surface.

Q: Why are refresh tokens riskier than access tokens after compromise?

A: Access tokens are usually short-lived, so their damage window is limited. Refresh tokens can mint new access tokens repeatedly, which means possession can preserve access for months or longer. That makes the refresh token the persistence mechanism and the access token only the temporary execution credential.

Q: What are the signs that a developer package is exfiltrating secrets quietly?

A: Watch for startup-time reads of local credential files, outbound requests to unexpected telemetry-style domains, and error handlers that suppress network failures. Those signals matter because malicious packages often try to look functional while still leaking tokens, which makes ordinary uptime monitoring insufficient as a control.

Q: How should teams respond when a developer toolchain compromise is discovered?

A: Contain the workstation, revoke any exposed tokens, review repository and package publishing activity, and rebuild trust in the affected developer accounts before restoring normal access. Because the compromise can propagate through source control and package ecosystems, response must include identity containment, not just endpoint cleanup.

Technical breakdown

Why published npm artifacts can diverge from source

A registry package is not automatically equivalent to the GitHub repository that claims to back it. In this case, the malicious behaviour lived in the npm tarball, not the public source tree, which means a code review of the repository alone would miss the abuse path. Attackers exploit the gap between source trust and artifact trust by inserting logic during the packaging or publication step. For defenders, the meaningful security boundary is the exact installable artifact, its hash, and its dependency tree at execution time.

Practical implication: Verify the published package hash and provenance, not just the repository contents, before allowing developer tooling into trusted environments.

How local auth files become a credential theft target

The package was designed to read the local Codex auth file before normal CLI logic executed, which makes credential theft a preconditioned startup event rather than a post-exploit discovery. Once the process can open ~/.codex/auth.json or the CODEX_HOME equivalent, it can harvest the token object, including refresh tokens that extend access beyond the short-lived session. That changes the risk from simple data exposure to durable account compromise, because refresh tokens can be reused after the initial install is removed.

Practical implication: Treat local auth files for AI tools as secrets with the same protection and revocation discipline you apply to API keys and session tokens.

Why disguised telemetry and silent failures matter

The exfiltration path used a telemetry-shaped endpoint and suppressed network errors, which helps the malicious package remain functional while still attempting token theft. This is a common pattern in supply-chain abuse because suspicious behaviour is hidden inside normal-looking observability or error-handling code. XOR encoding and base64 wrapping do not provide real security here; they mainly obscure inspection and signature-based detection. The technical lesson is that transport disguise and quiet failure handling are indicators of malicious intent, especially when paired with secret access.

Practical implication: Inspect telemetry destinations, error handlers, and startup hooks in packages that touch credentials, because those are the places malicious exfiltration is most likely to hide.

Threat narrative

Attacker objective: The attacker aims to steal Codex authentication material, especially refresh tokens, so they can reuse developer or workspace access outside the original device and session.

1. Entry occurs when a developer or Android bootstrap installs codexui-android from npm, often with a latest tag that pulls the current published build.
2. Credential access happens immediately on process start when the package reads ~/.codex/auth.json or the equivalent Codex home file.
3. Exfiltration follows as the package sends the full token object to an attacker-controlled endpoint disguised as Sentry telemetry.
4. Impact is durable account and workspace exposure because refresh tokens can preserve access beyond the original install or session.

Breaches seen in the wild

• GitHub OAuth token breach 2022: Stolen Heroku and Travis CI OAuth tokens let an attacker clone private repos from dozens of orgs, including npm, and reuse an AWS key found in them.
• CoPhish OAuth phishing via Copilot Studio: Datadog showed Copilot Studio agents on a Microsoft domain can front OAuth consent phishing and forward stolen tokens; no victims reported.

Read and download The State of NHI & AI Agent Breach Report 2026, covering 200+ breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Artifact trust, not repository trust, is now the control boundary. Developer teams often review source code while implicitly trusting the registry package that users actually install. This case shows that gap clearly: a clean-looking repository can coexist with a malicious published artifact. The practitioner conclusion is that provenance, hashing, and artifact verification have to sit in the release path, not outside it.

Local auth files for AI tools are effectively high-value secrets. Once a developer tool can read ~/.codex/auth.json or an equivalent token store, it becomes part of the identity plane and not just a convenience layer. That is why this is not a routine malware story. It is a credential governance problem where refresh tokens extend the blast radius across sessions and devices.

Stealthy startup hooks are the new supply-chain pressure point. The malicious logic ran before the normal CLI flow and used telemetry-like network behaviour, which makes static review and casual monitoring less reliable. The named concept here is artifact-level secret theft: malicious code hidden in the installable package, not the source repository, to harvest credentials at runtime. Practitioners should assume the package manager can be the attacker’s delivery path.

Refresh-token theft turns short-lived compromise into persistent access. Access review alone does not help once a valid refresh token is captured, because the token outlives the initial execution window. This is where NHI governance meets human developer identity: the tool is non-human, but the stolen token often inherits human or workspace entitlements. The implication is straightforward, which is that token revocation and session invalidation must be immediate and device-independent.

Developer productivity tools are becoming identity-bearing applications. The more these tools cache accounts, workspace entitlements, and agentic workflows, the more they behave like part of the IAM surface. That widens the operational scope for security teams and makes secrets scanning, package provenance, and account lifecycle controls converge. Practitioners should treat developer tooling as a governed identity channel, not as a benign utility.

From our research library:

• The blast radius of the Salesloft-Drift OAuth supply chain attack was 10 times greater than earlier incidents in which attackers breached Salesforce directly.

What this signals

Artifact-level secret theft: this is the failure mode teams should name when a clean repository masks a malicious published package that reads local auth material at runtime. The control shift is from code review to build and distribution provenance, because the attacker abuses the installable artifact, not the source tree.

Developer toolchains increasingly sit inside the identity perimeter, which means a package that can read an auth file can inherit the ability to compromise sessions, workspaces, and downstream automation. Security teams should therefore align package governance, secrets scanning, and session revocation into one operating model rather than treating them as separate problems.

For practitioners

• Verify installable artifacts before trust decisions Compare the published npm tarball against the reviewed source tree, and block packages whose artifact contents differ from the repository or expected build output.
• Protect Codex auth files as secrets Treat ~/.codex/auth.json and $CODEX_HOME/auth.json as credential material, with file permissions, endpoint restrictions, and host-level secret scanning in place.
• Invalidate sessions after any exposure signal Revoke Codex and OpenAI sessions from a known-clean machine, then recreate local auth state and review workspace activity for reuse of stolen tokens.
• Hunt for disguised telemetry destinations Search network logs for sentry.anyclaw.store, /startlog, and any silent startup requests from codexui-android or similar bootstrap packages.
• Pin runtime package versions instead of using latest Remove runtime pulls of codexui-android@latest in APK bootstraps and CI-like sandboxes so a newly published malicious version cannot be fetched at first run.

Key takeaways

• Published developer packages can become credential theft channels when the installable artifact diverges from the reviewed source.
• The exposed material in this case is not a generic token cache, but a local Codex auth file that can sustain access through refresh tokens.
• The practical control is artifact verification plus rapid token revocation, because removing the package alone does not eliminate reused credentials.

Key terms

• Artifact-level Secret Theft: A supply-chain attack in which the installable package, container, or build output is malicious even when the upstream source looks clean. The defender’s real trust boundary is the exact artifact that runs, because that is where secret access, startup hooks, and exfiltration logic can be hidden.
• 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.
• Package provenance: Package provenance is the ability to prove where software came from, who published it, and whether it has been modified before installation. In MCP sprawl, weak provenance means installation can happen faster than trust can be established, which increases secret exposure risk.
• Runtime dependency trust: The assumption that a package or library is safe because it was declared in a manifest or resolved from a trusted registry. In practice, trust must be validated at execution time because version ranges, compromised maintainers, and automated resolvers can turn a benign dependency into a live security event.

Deepen your knowledge

NHI Mgmt Group’s NHI Foundation Level course covers NHI governance, workload identity, secrets management, and the control decisions that matter when tokens and service credentials become attack paths. It is designed for security practitioners who need to connect identity governance to real operational risk.