An Infostealer Now Grabs .claude.json and Codex's config.toml. Check What Yours Hold

If you run any of those tools, the useful question is what those files hold on your machine right now.

The new capability is recent. "Earlier versions of the malware did not target AI-related files, which indicates the capability is a recent addition," the report says. The same sample still takes the usual haul: dozens of browsers, crypto wallets, password managers, messaging apps, and VPN and FTP clients.

Why would a thief want your coding agent's token? Symantec spells it out: a stolen token "can allow attackers to carry out activity under a legitimate user's identity and API quota," and can reach the repositories, cloud services and CI/CD pipelines linked to it ( Symantec ). It also notes that "a stolen AI key can be cashed in directly, either through resale or by running up usage on the victim's account." Infosecurity Magazine ties that to the practice known as LLMjacking.

The report leaves several things out. It doesn't say how Aoki gets onto a machine. It doesn't name the group behind it, and Symantec sees no link to an existing malware family ( Infosecurity Magazine ). It gives no victim count. Nothing in it describes a flaw in Claude Code, Codex or any other agent: Aoki reads files that are already on disk, after it is already running as you.

The new target is the folder your coding agent keeps in your home directory.

Each agent stores sign-in state differently, and the docs say where.

Claude Code. On macOS, your login lives in the encrypted macOS Keychain, per Anthropic's authentication docs. On Linux it lives in ~/.claude/.credentials.json with file mode 0600, and on Windows in %USERPROFILE%\.claude\.credentials.json. The same page says macOS falls back to that file "when the Keychain rejects the write, such as when it's locked in an SSH session." The file Symantec names, ~/.claude.json, is where Claude Code keeps MCP servers you add at local or user scope ( MCP docs ). The docs recommend local scope for "servers with credentials you don't want in version control." That keeps a token out of git. It doesn't keep it out of your home directory.

Codex. OpenAI's docs say Codex "caches login details locally in a plaintext file at ~/.codex/auth.json or in your OS-specific credential store," and add: "treat ~/.codex/auth.json like a password: it contains access tokens." Symantec's list names Codex's config.toml, not auth.json. In config.toml, the env table of a stdio MCP server sets variables for that server's process ( Codex MCP docs ), so a key typed there as a literal value sits in the file as plain text.

You don't need to guess. These only read and print. They list which credential files exist, then look for token-shaped strings in the two config files Symantec names:

ls -l ~/.claude/.credentials.json \ ~/.codex/auth.json 2>/dev/null grep -nE 'Bearer |sk-|ghp_|github_pat_|_KEY|_TOKEN' \ ~/.claude.json ~/.codex/config.toml 2>/dev/null Enter fullscreen mode Exit fullscreen mode On Linux, a.credentials.json from ls is the expected place for your Claude Code login. On macOS it means the Keychain write failed and the login fell back to a file. An auth.json means Codex is caching your login in a file; the next section moves it.

The grep is noisy on purpose. A variable name like GITHUB_TOKEN with no value next to it is fine. A long literal value next to it is the thing to fix. Run the same grep across any.env files in your projects, since Symantec lists.env files too.

Treat what you find as a cleanup list. A hit doesn't mean you were infected. These files being readable by your user is normal. The risk only exists once something hostile is running as you, and that is exactly the case the report describes.

A token in the OS credential store versus a token in a plain file.

For Codex, the fix is a setting. cli_auth_credentials_store controls where the CLI caches credentials: file, keyring, auto, or ephemeral ( OpenAI docs ). keyring uses your OS credential store "and fails if it is unavailable":

# ~/.codex/config.toml cli_auth_credentials_store = "keyring" Enter fullscreen mode Exit fullscreen mode Then run codex logout and sign in again with codex login, so the next token lands in the keyring instead of auth.json.

For MCP servers, stop pasting literal tokens. Codex's bearer_token_env_var takes the name of an environment variable instead of the token itself ( Codex MCP docs ). For Claude Code, if a remote server uses OAuth with pre-configured client credentials, the client secret is stored "in your system keychain (macOS) or a credentials file, not in your config" ( MCP docs ). An environment variable is not a vault, though. If you export the key from ~/.zshrc, you've moved the plain text to a different file.

For Claude Code's own API key, the apiKeyHelper setting runs a script that returns the key, so the key can come from a keychain instead of your shell profile.

Rotation beats cleanup. Once a token has left the machine, deleting the file does nothing. Signing out has a limit too: it clears the copy on this machine, and neither vendor's docs say it kills a copy that was already taken. Revoking API keys at the source is the step that counts.

For network hunting, Symantec publishes 17 file hashes and these command-and-control domains, which you can check against DNS logs: dobeqnesmot[.]cc, hjazfioe[.]surf and neihite[.]cc ( Symantec ).

I build Hermes IDE, so weigh this with that in mind. Hermes runs each agent with its own CLI sign-in and "never asks for tokens," per its README. So you don't hand it your Claude or Codex tokens, and it doesn't protect them either: the files above are each agent's own, and the Codex setting and the token cleanup are still yours to do. Since 2.3.2, Hermes's terminal suggestions never offer back commands that set an API key or pass an auth header ( release notes ). Your shell's own history is unchanged, so that's still worth a separate look. Hermes is not affiliated with Anthropic, OpenAI, Symantec or any agent vendor named here.

A coding agent's token is an identity: whoever holds it runs the agent as you, on your quota and your repos. The AI Agents Pocket Guide covers the guardrails around that, from tool permissions to how much autonomy an agent gets before a human checks in.

If you run several agents side by side, Hermes IDE is free and source-available for macOS, Windows and Linux, and it keeps each agent on its own sign-in. It's on GitHub.