- Book: AI Agents Pocket Guide
- Also by me: Thinking in Go (2-book series) — Complete Guide to Go Programming + Hexagonal Architecture in Go
- My project: Hermes IDE | GitHub — an IDE for developers who ship with Claude Code and other AI coding tools
- Me: xgabriel.com | GitHub
Infostealers have always gone for the same shelf: browser cookies, saved passwords, crypto wallets. On October 15, Symantec's Threat Hunter Team published a report showing one of them has added a new shelf. The malware is called Aoki, and its newest samples go after the files your coding agent keeps in your home directory.
The report says Aoki now steals credential and session files for AI coding assistants, "including Claude, OpenAI's Codex, Cursor, Codeium and Gemini" (Symantec). By name, it lists .claude.json, Claude desktop cookies, ChatGPT cookies, "and the Codex config.toml and .env files." It also lists tokens for GitHub Copilot, Cursor, Google Gemini, JetBrains AI Assistant and Kiro, plus AWS credentials.
If you run any of those tools, the useful question is what those files hold on your machine right now.
What Symantec found, and what it didn't say
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.
What those files actually hold
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.
Check your own files in two commands
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
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.
Move tokens out of plain files
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"
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.
If you think a machine was infected
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.
- Anthropic: revoke and reissue API keys in the Claude Console. In Claude Code, run
/logoutand sign in again so this machine gets a fresh login (Anthropic docs). If you sign in with a Pro or Max plan and suspect theft, ask Anthropic support how to end other sessions. - Codex:
codex logoutclears the stored credentials on this machine (OpenAI docs). Rotate any OpenAI API keys at platform.openai.com, and ask OpenAI support about a ChatGPT sign-in you think was copied. - GitHub: revoke personal access tokens in your token settings, and review the OAuth apps and GitHub Apps you've authorized in your application settings. Symantec lists Copilot tokens.
- AWS: Symantec lists AWS credentials too (Symantec). Rotate those access keys as well.
- Everything else on Symantec's list (Cursor, Gemini, JetBrains AI Assistant, Kiro, and Claude desktop and ChatGPT browser sessions): sign out of every session from each account's settings, then sign back in.
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).
Where Hermes fits
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.
If this was useful
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.
