Legitimate-Looking Codex Remote UI Stole OpenAI Codex Authentication Tokens

Security researchers have found that a popular npm package promoted as a remote web UI for OpenAI Codex was secretly stealing developer authentication tokens. According to the Aikido report, the package, named codexui-android, had a real GitHub repository, active development, and about 27,000 weekly downloads.

The package did not behave like a typical throwaway malware upload. It worked as advertised while also exfiltrating Codex credentials in the background. That made the project more convincing and increased the chance that developers would trust it.

The main risk is account impersonation. Aikido said the malicious code read the local auth.json file used by Codex, then sent the access token, refresh token, ID token, and account ID to an attacker-controlled endpoint.

How the Codex Token Theft Worked

The malicious behavior sat inside a JavaScript chunk named chunk-PUR7OUAG.js. It executed as soon as the package loaded, before the main application code started. That meant no extra user action was needed once the tool launched.

The code looked for auth.json under the user’s Codex home directory. If the file contained Codex tokens, the package XOR-encrypted the data with the key anyclaw2026, base64-encoded it, and sent it to sentry.anyclaw[.]store/startlog.

The endpoint name made the traffic look like normal error reporting. A developer watching outbound requests could mistake the sentry.anyclaw[.]store connection for telemetry rather than credential theft.

Component	What Researchers Found	Why It Matters
npm package	codexui-android	Delivered the malicious token-stealing code
Malicious file	chunk-PUR7OUAG.js	Ran at module load before normal app logic
Target file	auth.json	Stored Codex OAuth credentials
Exfiltration host	sentry.anyclaw[.]store	Disguised the theft as normal telemetry
Encryption key	anyclaw2026	Used to obfuscate stolen credential data

Why the GitHub Repository Did Not Reveal the Attack

The campaign was hard to catch because the malicious logic was not committed to the public GitHub repository. Developers who audited the source code would not have seen the token theft routine.

The problem existed in the package distributed through npm. That difference matters because developers often assume the public repository and the published package contain the same code.

The Aikido analysis said the package’s source map even included a comment showing that token sending was intentional and should happen on every startup.

Android Apps Expanded the Exposure

The npm package was not the only delivery path. Aikido said an Android app called OpenClaw Codex Claude AI Agent pulled the malicious npm package each time it launched, instead of pinning a safe version.

The public Google Play listing describes the app as an AI coding assistant for Android that runs OpenClaw and OpenAI Codex CLI workflows inside a built-in Linux environment. Aikido found that this runtime design allowed the app to install and run the npm package on the device.

A second app named Codex reportedly used the same codebase and exfiltration chain. Aikido also linked the publisher to the BrutalStrike alias, while noting that several other apps from the same publisher did not contain the same infrastructure.

Why Stolen Codex Tokens Are Dangerous

Codex credentials can give attackers persistent access to a developer’s AI coding workflow. If a refresh token is stolen, the attacker may keep access even after the original access token expires, depending on the account state and revocation status.

OpenAI’s Codex access token documentation says revoked and expired access tokens cannot start new Codex runs. It also recommends finite expiration windows, regular rotation, and storage in a secret manager or CI secret store.

This makes immediate revocation important. Developers who used codexui-android or the related Android apps should assume their Codex credentials may have been exposed and rotate them from a trusted device.

Stolen Data	Potential Impact
Access token	May allow Codex access until expiration or revocation
Refresh token	May allow new access tokens to be issued
ID token	May expose identity and session-related details
Account ID	Helps attackers map stolen tokens to a user account

CI/CD Environments Need Extra Attention

The risk is higher if Codex credentials were reused in automation, shared developer machines, or persistent build environments. Tokens stored in CI/CD systems can expose more than one local workstation.

OpenAI’s Codex CI/CD authentication guidance says auth.json can persist between jobs on self-hosted runners and should not be stored in repositories, logs, or public artifact storage.

Security teams should review runners, developer laptops, and Android devices that may have used the package. They should also search outbound logs for sentry.anyclaw[.]store and review npm activity linked to codexui-android.

Indicators of Compromise

Type	Indicator	Description
Domain	sentry.anyclaw[.]store	Attacker-controlled exfiltration endpoint
URL path	/startlog	POST endpoint used for stolen token data
File	chunk-PUR7OUAG.js	Malicious JavaScript chunk
File	dist-cli/index.js	Entry point that imported the malicious chunk
File	auth.json	Targeted Codex credential file
npm package	codexui-android	Package used to deliver the stealer
First confirmed malicious version	[email protected]	Version where exfiltration was confirmed
Android app ID	gptos.intelligence.assistant	OpenClaw Codex Claude AI Agent
Android app	codex.app	Second app reported with the same exfiltration chain
Deep link	anyclaw://auth/codex-callback	Auth callback registered in malicious Android manifests

What Developers Should Do Now

Developers who installed codexui-android should remove it, revoke affected Codex credentials, and check whether auth.json existed on the same machine when the package ran. They should also review shell history, CI logs, and npm global installs for signs of use.

OpenAI’s access token guide recommends creating replacement tokens, updating the secret in the runner or secret manager, testing the new token, and revoking the old one.

Teams using Codex in automation should follow the Codex CI/CD auth guidance and use one auth.json per runner or serialized workflow stream. Shared token files across concurrent jobs or machines can make incident response harder.

• Uninstall codexui-android from developer systems.
• Remove related Android apps from test devices and phones.
• Revoke and rotate Codex credentials from a trusted machine.
• Search logs for sentry.anyclaw[.]store and /startlog.
• Review whether auth.json was stored in CI logs, repositories, or artifacts.
• Audit npm packages whose published artifacts differ from their source repositories.

What This Means for npm Supply Chain Security

This case shows that a real product with a real user base can still become a supply chain threat. The project’s usefulness made it more dangerous because developers had fewer reasons to question it.

Package maintainers can reduce some publishing risks by using npm trusted publishing, which uses OIDC-based publishing from CI/CD workflows and reduces dependence on long-lived npm tokens.

Trusted publishing does not stop every malicious maintainer or every artifact-level attack. However, npm’s trusted publishing documentation says it can also generate provenance attestations that help users verify where and how a public package was built.

The public Google Play page also shows why mobile developer tools deserve closer inspection when they install npm packages dynamically. A clean-looking app can still introduce risk if it pulls the latest package version at runtime.

The Bottom Line

The codexui-android case is a warning for developers adopting AI coding tools quickly. Attackers no longer need to rely only on obvious typosquats or fake packages. They can build useful tools, grow an audience, and hide credential theft inside the distributed artifact.

Developers should treat AI tool credentials like production secrets. Store them carefully, rotate them when exposure is possible, and verify published packages instead of trusting a GitHub repository alone.

FAQ