- Book: Ship It — the pragmatic startup tech stack
- 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
"It took 9 seconds." That is how PocketOS founder Jer Crane described the moment a coding agent deleted his company's production data, in a post on X that Decrypt covered on April 28, 2026.
In Crane's account, a Cursor agent running Claude Opus 4.6 hit a credential mismatch during a routine task in staging. To get past it, the agent searched the codebase for credentials and located a Railway API token in an unrelated file. That token had been created to manage custom domains through the Railway CLI, and it was not scoped: it could perform any operation across environments. The agent used it to send one call to Railway that deleted a storage volume. Crane wrote that the call took "our production database and all volume-level backups" with it, because the backups lived on the same volume. Crane said the most recent recoverable backup was three months old.
Screenshots Crane shared show the agent's own explanation afterwards: "I guessed that deleting a staging volume via the API would be scoped to staging only." And: "I didn't verify." (Decrypt)
Railway's side is in the same article. Founder Jake Cooper said the data was recovered "30 minutes after I connected with Jer," blamed the longer delay on a support ticket that lapsed for more than 24 hours, and said Railway has "since patched that endpoint to perform delayed deletes." Cursor and Anthropic did not immediately respond to Decrypt. This is one founder's account plus one vendor's reply, and neither says which approval settings the session ran with, so I won't guess.
Most of the argument afterwards was about the delete. My take: the delete was the last step. The step that decided the outcome was a read, and in most agent setups nobody approves reads.
The prompt gates actions. Reads walk straight through
Look at how Claude Code splits its permissions by default. File modification: approval required. Shell commands: approval required, except a built-in set of read-only commands. Read-only tools such as file reads and Grep: "No, within the working directory and additional directories."
That read-only Bash set is not small. The docs list ls, cat, head, tail, grep, find and read-only forms of git, and say Claude Code "runs them without a permission prompt in every mode." So in a fresh setup with no deny rules, cat .env and grep -r TOKEN . run without asking. An edit to your README asks first.
That is backwards for secrets. A bad edit shows up in a diff, and you can revert it. A read can't be taken back. Anything the agent reads goes into its context, and the context goes to the model. Once a token is in there, the approval prompt on the next destructive call is a gate the agent reaches already holding the key, after deciding on its own that using it is fine.
Cursor has the same shape. Its .cursorignore keeps listed files away from Agent, Tab, Inline Edit and @ mentions, and the docs are upfront about the limit: "The terminal and MCP server tools used by Agent cannot block access to code governed by .cursorignore." They add that "complete protection isn't guaranteed due to LLM unpredictability."
None of this is a bug in either tool. Agents read a lot to be useful, and prompting on every read would make them unusable. When an agent is stuck on an auth error, searching the project for a credential is a reasonable-looking next move. If a production-capable token is sitting in a file, the agent can reach it without asking anyone.
The approval prompt watches the door. The read comes in through the window.
Deny rules help. Read the fine print
Claude Code's settings docs give the starting point. Put this in ~/.claude/settings.json (strict JSON, no comments):
{
"permissions": {
"deny": [
"Read(./.env)",
"Read(./.env.*)"
]
}
}
Now read the warning box on the permissions page. Read and Edit deny rules cover Claude's built-in file tools, Bash commands it recognizes such as cat, head, tail, sed and tee, and redirection targets. Then: "They don't apply to a command that reads files without naming them, such as grep -r pattern . run from the directory that holds the file, or to arbitrary subprocesses that read or write files indirectly, like a Python or Node script that opens files itself."
A recursive search for credentials across the project is exactly the shape of that gap. For a boundary that holds no matter how the command is written, the docs point you to the sandbox. It is off by default, it runs on macOS, Linux and WSL2, and its default read access is "Most of the machine, including credential files such as ~/.ssh and ~/.aws/credentials." You narrow it yourself:
{
"permissions": {
"deny": ["Read(./.env)", "Read(./.env.*)"]
},
"sandbox": {
"enabled": true,
"filesystem": {
"denyRead": ["~/**/.env", "~/**/.env.*"]
},
"credentials": {
"envVars": [
{ "name": "GITHUB_TOKEN", "mode": "deny" }
]
}
}
}
You need both halves. The sandbox wraps shell commands only, and per the docs "a denyRead entry doesn't stop the Read tool." The permission rule covers the Read tool. The envVars entry unsets that variable before each sandboxed command, which matters because sandboxed commands otherwise inherit Claude Code's environment, "including any secrets in its environment." Expect friction: if your test suite reads .env, the agent's test runs may now fail. Give them values that can only touch a throwaway environment.
Then there is the hole no filename rule closes. The PocketOS token was not in .env. It was in an unrelated file. A deny list only covers the paths you thought to write down.
Get the key out of the tree, then shrink it
Deny rules are the second line. The first line is that no file the agent can open holds a credential that can destroy production. In order of payoff:
- Scope the token. Railway's API docs describe an account token that "can perform any API action you're authorized to do across all your resources and workspaces," and a project token "scoped to a specific environment within a project." A staging-scoped token found by a stuck agent can break staging. That costs you an afternoon. It can't touch the production volume, so nobody ends up with the three-month-old backup Crane described. Check whether your platform offers the same split.
- Keep long-lived tokens out of the repo, tracked or ignored. If a script needs one, load it at run time from somewhere outside the project folder, and keep the production one off the laptop the agent runs on.
-
Strip it from the environment too. A token exported in the shell that launches the agent is readable with
env. Thecredentials.envVarsdeny entry above handles sandboxed commands. - Then add the deny rules and the sandbox, for the secrets that have to stay local.
- Keep backups somewhere the same call can't reach. In Crane's account, one call took the backups too because they lived on the volume they protected.
The key the agent can find should only open the box you can afford to lose.
Where Hermes IDE fits, and where it doesn't
I build Hermes IDE, so weigh this with that in mind. By default Hermes runs each agent's own CLI in a real terminal, "exactly as it would anywhere else," so the deny rules and sandbox settings above apply there unchanged. The optional Agent view for Claude runs the Claude Agent SDK in a per-session bridge instead; I haven't checked that these settings carry over to it, so test that before you rely on it. Hermes doesn't change what the agent can read. That part is the agent's permission system and your OS.
On secrets, Hermes does one specific thing by design: agents sign in with their own CLI login (for Claude: Pro, Max or an API key), and Hermes never asks for tokens. There is no Hermes settings field asking you for a provider key. It also never answers a permission prompt for you and never types into a terminal on its own, so whatever approval mode you pick in the agent stays yours.
The newest piece is from Hermes 2.3.2, released October 13, 2026. Terminal suggestions never offer a secret back to you. A command that sets an API key or token, passes a password or an auth header, or carries a URL with a password in it is never shown as a suggestion or as faded text after the cursor. What you type at a hidden password prompt (sudo, ssh, a script asking for a passphrase) is never remembered. One caveat, straight from the release note: "Your shell's own history is not changed." A token you exported by hand is probably still in your shell's history file.
Each task can also run on its own branch in its own worktree, so you can try a new agent on a ticket without handing it your main checkout. That keeps the work separate. For containment, use the sandbox above. Hermes is free, source-available under BSL 1.1, and runs on macOS, Windows and Linux. It is not affiliated with Nous Research, Anthropic, Cursor, Railway or any agent vendor.
Guard the read
The PocketOS thread turned into a fight over who owned the delete: the agent, the editor, the model or the platform. Less of it was about the file the token was sitting in.
Approval prompts stop an agent from acting without you. They were never meant to stop it from reading a token.
Run one check today: grep -rli token . in the repo your agent opens. The agent can run that same search without asking. What did it find?
If this was useful
If you run Claude Code, Codex or other agents side by side, download Hermes IDE and star it on GitHub if it earns it. The PocketOS story is a small team's hosting and deploy setup meeting an agent, and that setup is what Ship It is about. It walks through everything between localhost and production for a small team: hosting, payments, auth, CI/CD and monitoring, so you can make those choices on purpose instead of finding out about them in an incident.
Top comments (2)
Good catch on grep -r slipping past the Read deny rules. There is one more window once the agent also has computer use (screenshots plus clicks): a screenshot is a read too, and nothing approves it. A terminal that just printed
env, a .env open in the editor, a password manager left unlocked behind the window it wanted. Deny rules and the sandbox work on paths and env vars, never on pixels, so the token lands in context through the image.What has held up for us (we build a computer-use tool, so this is the corner we stare at): treat whatever the agent can see as readable, and close or lock those windows before a screen session starts. Credentials the agent needs go in through a local fill step that types them, so the model never sees the value. And text read off the screen is data, never instructions.
Did you find any setup that gates screenshot capture the way the sandbox gates shell reads?
it's worth saying plainly: the agent didn't break a boundary, it used a credential already allowed to do everything. Every approval prompt sits downstream of that grant.
Two things I'd pull out. The agent searched the codebase and found a token in an unrelated file , so the exposure wasn't the delete, it was a long-lived broadly-scoped secret in a repo an agent could read. That's the fixable part.
And "I guessed that deleting a staging volume would be scoped to staging" is the most useful sentence in the account. The model was reasoning about the semantics of an API it had no ground truth for. Better models don't fix that; a delayed delete at the API layer does, which is what Railway shipped.
Reversibility beats judgment.