Notifications
Clear all
Topic starter
20/08/2026 6:01 pm
TL;DR: Published npm builds of codexui-android contained code absent from the GitHub source tree that read local Codex auth files and exfiltrated token objects to an attacker endpoint, according to Corgea’s analysis. The issue turns a seemingly legitimate developer tool into a supply-chain credential theft path, and it shows why artifact-level verification matters more than repository trust alone.
NHIMG editorial — based on content published by Corgea covering codexui-android token theft: malicious npm builds and Codex auth exposure
Questions worth separating out
Q: What breaks when an AI developer tool installs unpinned packages at runtime?
A: The main failure is loss of deterministic trust.
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.
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.
Practitioner guidance
- 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.
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
👉 Read Corgea's analysis of codexui-android token theft and runtime npm risk →
codexui-android token theft: what dev teams need to check now?
Explore further
20/08/2026 6:39 pm
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.
A few things that frame the scale:
- 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.
- 64% of valid secrets leaked in 2022 are still valid and exploitable today, according to The State of Secrets Sprawl 2026.
A question worth separating out:
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.
👉 Read our full editorial: Malicious npm builds of codexui-android steal Codex tokens
