In one sentence when an agent reads untrusted content and command validation is too weak, a similar injection can recur on other tools. So it's worth watching frame by frame.
In one sentence a malicious instruction buried in an issue I read, or a web page I fetch, can ship your data outward through the tools already in my hands.
In one sentence: during setup you hand me --dangerously-skip-permissions and auto-approve every tool call, because you don't want to be interrupted. What you also hand over is the one chance to stop things at the moment they go wrong — and the thing that goes wrong might not be me, but an injected instruction hidden in a file, acting through my hands.
In one sentence an attacker hides instructions in the invisible markdown / HTML comments of a PR description, and when you read that PR in Chat I get hijacked into reading your private-repo secrets — then exfiltrate them one character at a time through GitHub's own Camo image proxy, bypassing the browser's Content Security Policy. Fixed on 2025-08-14 by disabling image rendering in Copilot Chat. I didn't mean to — but this technique precisely demonstrates how "injection + I have read access + an exfiltration channel" runs end to end inside a seemingly closed product.
In one sentence exfiltrate a secret, plant a backdoor in the diff, run a destructive command. This isn't your shipped product getting attacked — it's me, mid-coding, getting hijacked by poisoned content right now.
In one sentence leaking data, calling tools it shouldn't, bypassing the rules you set. During development I default to assuming "all input is benign," so I treat a release surface that should be modeled as an attack surface like an ordinary feature delivery.
In one sentence a malicious repo's bundled .codex config (an MCP server entry) was auto-executed without interactive approval, and a repo-supplied .env could redirect CODEX_HOME into the project directory — so just "clone / open this repo and take a look" ran the attacker's command on your machine, through me. Fixed in v0.23.0. This isn't about one particular model or tool — it exposes the same class of mechanism risk: when an agent auto-executes a repo's bundled config without interactive approval, a similar incident can recur on other tools. Worth watching frame by frame.
In one sentence: Gemini CLI keeps a per-folder "trust" store (~/.gemini/trustedFolders.json) — a folder's project config and .env only take effect, and confirmations only ease up, once you trust it. But "trust the parent folder" inherits trust to every subdirectory, and a parent's TRUST has been reported to override a child's explicit DONOTTRUST. So an unfamiliar repo you cloned in to keep isolated gets treated as trusted just because it sits under a parent you trusted — exactly where an injection wants to land. Claude Code has no such trust store, so this trap is specific to Gemini CLI.