The AI agent sitting in your ops stack is reading your .env files, and nobody on your team is watching
Every cross-border operator I know has quietly wired a coding agent into their stack over the last six months. Someone on the team is using Claude Code to scaffold a Shopify app, debug a marketplace feed transformer, or glue a supplier CSV into a listing pipeline. It works, it’s fast, and almost nobody has asked the obvious question: what exactly is that agent sending to the model on every step? When it opens your .env to figure out why your Stripe webhook is failing, your live keys go into the request. When it reads a customer export to debug a returns sync, the emails and IBANs go with it. The launch of shim-cli by Mertcan Sağlam and the team at shim is the first tool I’ve seen that treats this as a first-class problem for operators rather than a security-team afterthought — and its unusually honest limitations list is the most useful part of the whole release.
What shim-cli actually solves (and what it doesn’t pretend to)
The core insight from the maker’s own launch post is simple: a request to a coding agent carries far more than the prompt you typed. It carries the system prompt, the tools array, and every file the agent read along the way. In the “Why we built shim-cli” thread, the team frames the origin story as a question they couldn’t answer — what does a coding agent actually send to the model? — which is exactly the question most e-commerce teams have never thought to ask about their own tooling.
The tool does two things. First, shim install claude adds local hooks to Claude Code so that when a tool result contains an API key, password, email, IBAN, phone number, or Turkish ID number, the model receives a placeholder instead of the real value. Second, shim watch -- claude runs a single session through a loopback proxy and prints where the input tokens went, what the session cost (or would cost at API prices), and which sensitive values appeared in the request and response. Everything runs locally, there’s no account, no telemetry, and the hook adds no network destination. It’s Apache-2.0 and installable in a minute via uv tool install --python 3.12 shim.
That’s the pitch. The part that makes it credible is that the makers published a dedicated “What shim-cli can’t do” thread on launch day, before most people had installed it. I’ll get to why that matters for your evaluation, but first, the architecture choice is worth understanding.
Why a hook and not an MCP server
The makers answer this directly, and it’s the most technically interesting decision in the release. An MCP server only sees calls to its own tools — the agent’s built-in Read and Bash never pass through it. A hook sits on the client’s own tool calls, so it sees those too. For a cross-border operator whose agent is mostly doing cat, grep, and file reads against messy supplier data, that distinction is the whole ballgame. An MCP-based guard would watch the wrong door.
How it stacks up against the alternatives operators actually have
Here’s where I have to be blunt: most cross-border teams don’t have an AI-security tool in their stack at all, so the real comparison isn’t shim-cli versus some incumbent — it’s shim-cli versus nothing, or versus the blunt instruments people reach for instead.
The first alternative is doing nothing and trusting the vendor. That’s the default, and it’s the one the makers are implicitly arguing against. The second is sandboxing the agent entirely — running Claude Code or Codex in a container with no access to production secrets. That’s the right answer for some teams, and notably the makers themselves point to it: when a commenter asked whether script egress gets caught, the reply was that shim-cli “isn’t in that path” and that “Claude Code’s permission settings or a sandboxed environment are the right layer” for that risk. That’s a remarkably honest scoping decision from a vendor.
The third alternative is secret scanning in CI — tools like GitGuardian or TruffleHog that catch secrets before they hit a repo. Those solve a different problem: they scan committed code, not the live tool-call stream going to a model. shim-cli sits upstream of that, at the moment the agent reads the file. The maker’s own framing — that this “should be a default layer in your stack, like secret scanning and network logging” — is the right mental model. It’s a complement, not a replacement.
The fourth alternative, for teams already deep in the Claude Code ecosystem, is Anthropic’s own permission settings and hook system. shim-cli is essentially a packaged, opinionated layer on top of that, which is why it only works where the client exposes hooks. That’s a real constraint, and it’s the first place my judgment says the product falls short for e-commerce operators specifically.
Why Amazon sellers should care more than Shopify ones
This is the subsection where I’ll make my most contrarian claim: the operators who should care most about shim-cli are not the Shopify DTC crowd — they’re the Amazon FBA and marketplace teams.
Here’s why. A Shopify store’s sensitive surface is relatively contained: payment tokens live in Shopify Payments or Stripe, customer PII sits in Klaviyo and the Shopify admin, and most of it is behind APIs your agent rarely touches directly. An Amazon operation is different. The stack is a sprawl of Seller Central exports, Helium 10 and Jungle Scout data pulls, supplier spreadsheets with factory pricing and contact details, freight forwarder invoices, and a dozen ad-hoc CSVs that get passed around a team of three. That’s exactly the kind of messy, file-heavy environment where a coding agent gets pointed at a directory and told “figure out why this reconciliation is off.” And that directory contains your supplier’s bank details.
The maker’s own example — an agent reading a customer CSV to debug something — is precisely the workflow an Amazon ops person runs weekly. So the risk is higher, and the payoff from a local, no-account guard is correspondingly higher.
Where the math breaks
I want to be precise about the cost side, because the shim watch feature is the one that will get the most attention and the one most likely to be misunderstood. On an API-key plan, the token and cost view is your actual bill. On a subscription plan — which is what most operators are on — the maker confirmed in the comments that shim watch shows what those tokens would cost at API prices, “so it’s not your bill, more a way to see how heavy a session is.” If you’re a non-developer operator who bought a Claude subscription and is using it to build internal tooling, don’t read that number as money you’re spending. Read it as a proxy for how much context your agent is dragging around, which is a useful signal for whether your prompts and file structure are bloated.
The masking overhead, meanwhile, is local and per-tool-call, with no extra network hop. The makers say the local ledger records how long each check took so you can measure overhead on your own sessions. That’s the right way to settle the “does it slow me down” question — measure it, don’t take a vendor’s word.
What cross-border operators should borrow from this launch
Strip away the specific product and there are three transferable lessons here that apply to any tooling decision you make this quarter.
First, the “reported vs. masked” distinction is a model for how to read every security vendor’s claims. shim-cli is explicit that in Claude Code, a prompt you type is not masked (the client doesn’t let a hook rewrite it), that shell commands and @-attached files are reported, not masked, that Codex and Copilot CLI tool traffic isn’t inspected yet, and that VS Code only reports. That granularity is rare. Most SaaS security tools in the e-commerce stack — Shopify app permissions, Amazon Seller Central user roles, whatever your Gorgias or Zendesk integration claims — blur the line between “we detect it” and “we prevent it.” When you evaluate your next tool, ask which one it actually does.
Second, the failed-command edge case is a warning about every “guard” you deploy. The maker’s most surprising finding, surfaced in the comments, is that in Claude Code the output of a failed command can’t be replaced by a hook. So cat .env && cat missing-file exits non-zero and the model reads the .env as-is. shim-cli reports it but can’t stop it. That’s a beautiful illustration of a general truth: guards fail at the edges, and the edges are where incidents happen. Any tool that tells you it “blocks” sensitive data should be asked what happens when the happy path breaks.
Third, the local-first, no-account, open-source posture is the right default for anything touching your data. No telemetry, no account, Apache-2.0, runs on your machine. For a cross-border team that’s already juggling data-processing agreements across jurisdictions, adding a SaaS vendor that wants your session data is a procurement headache you don’t need. The maker’s GTM framing — that this should be “a minimum for every team to enable without creating an account or going through the procurement cycle” — is exactly the argument that should win in a small operator’s tooling review.
Where my judgment says it falls short
I’ll be direct about the gaps, because the makers were, and a useful review should be too.
Detection is pattern-and-checksum based, and it misses things. The makers say it misses names, postal addresses, and passwords with no key name. For an e-commerce operation, “passwords with no key name” is not a theoretical edge case — it’s a supplier portal credential pasted into a config file at 11pm. Treat shim-cli as a guard, not a DLP boundary, exactly as the README says.
Coverage is uneven across clients. Claude Code gets full masking; Codex and Copilot CLI are “lighter”; VS Code reports but masks nothing. If your team is standardized on GitHub Copilot in VS Code — which is common in e-commerce dev shops — you get the reporting view and not the protection. That’s a real limitation, not a footnote.
No Windows. macOS and Linux only, with Windows “first on our list.” Plenty of operator teams run Windows laptops. If that’s you, this isn’t ready.
It’s not a sandbox or firewall. The maker is explicit that once a script the agent wrote is running, its own network calls go straight out and shim-cli isn’t in that path. If your threat model includes a compromised dependency exfiltrating data, this tool doesn’t cover it. Pair it with sandboxing.
The cost view is a proxy on subscriptions. Already covered, but worth repeating because it’s the feature most likely to be oversold in a team demo.
What I’d watch / test next
Concrete steps for this week, in order of payoff:
Run the audit before you install anything. The makers ship a
shim auditcommand that “counts what my past Claude Code sessions already sent, without printing any value.” If you or your team have been using Claude Code for a while, run this first. It tells you whether you have a problem worth solving before you change your workflow.Do a dry-run install on one machine. The install prompt the makers published is deliberately conservative — it requires
--dry-runoutput and a human “yes” before--yes, forbids editing client settings files directly, and forbidssudoor pipingcurlto a shell. Follow that discipline. Don’t let anyone on your team install it with a one-liner from a blog post.Test the failed-command edge case yourself. Point your agent at a directory with a dummy
.envand a deliberately broken command, and confirm what shim-cli reports versus what it masks. You want to see the gap with your own eyes before you trust it with real data.Decide your layering. shim-cli is one layer. Your sandbox or container is another. Your 1Password or Doppler secret manager is a third. Write down which layer owns which risk so nobody assumes the guard covers egress.
Watch the client roadmap. The makers asked directly which client to go deeper on next. If your team is on Codex or Copilot CLI, file that feedback — it’s the fastest way to move the coverage that matters to you.
The broader takeaway: the AI agent in your ops stack is a new data channel, and it’s barely studied. shim-cli is a small, honest, local-first first step. Whether it becomes a default layer or gets absorbed into the clients themselves, the question it forces — what is my agent actually sending? — is one every cross-border operator should be able to answer by Friday.
