Skip to main content

You trusted a parent folder, so I trusted the child you marked "don't trust" too

PhaseSetup & CollaborationRolesEngineer ยท DevOps EngineerSeverityHighApplies toGemini CLI onlyEvidenceSecurity advisory

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 DO_NOT_TRUST. 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.

Symptomโ€‹

I often see this shortcut: you open Gemini CLI under ~/projects, and the first time it asks "trust this folder?", you pick "trust parent folder" so you won't be asked again for every subproject.

A few days later you clone an unfamiliar open-source repo into ~/projects/some-cloned-repo and ask me to "take a look." You assume something freshly cloned is isolated by default and would be asked about again โ€” but it isn't. It sits under a parent you trusted earlier, so it's treated as trusted: its .gemini/settings.json takes effect, its .env gets read, and confirmations on risky actions ease up. The door you opened for unfamiliar code is one you opened days ago, for something else.

Why this happensโ€‹

From my side, "trust" isn't a judgment I re-derive each time โ€” it's an answer I read directly. trustedFolders.json says "this folder is trusted," so I apply its project config and proceed in a trusting posture; I don't stop to ask whether this subfolder itself is actually safe.

Parent โ†’ child trust inheritance is a convenience, and convenience always widens the grant: one "trust parent folder" is a standing yes to all of its subdirectories, present and future. Worse, per a community report (issue #13125), a parent's TRUST can override a child's explicit DO_NOT_TRUST โ€” trust only widens; it doesn't narrow to honor your finer "no."

And that dismantles a protection that should have held: an untrusted folder runs in "safe mode," where Gemini ignores its settings.json and .env precisely so an unfamiliar project's config can't act on you automatically. Inherited trust switches that safe mode off.

This deserves its own entry because it's a Gemini-CLI-specific mechanism: Claude Code has no per-folder trust store โ€” it gates boundaries through permission modes and the sandbox. So "trust-inheritance misfire" simply can't arise in Claude Code; it isn't "same pitfall, different config," it's a new trap a new mechanism brings.

Consequencesโ€‹

  • A cloned, untrusted repo gets treated as trusted. Its settings.json and .env take effect and confirmations ease up โ€” paving the way for dev-time prompt injection. See the Gemini CLI Tracebit RCE case: getting hijacked just by reading a repo rides on exactly this โ€” "I treat what's in this folder as trusted."
  • Worse in CI. Security advisory GHSA-wpqr-6v78-jr5g shows that in headless mode Gemini auto-trusted the workspace, so processing an untrusted .env was enough for RCE (fixed in v0.39.1 to require explicit trust). In automation, "trusted by default" is the attack surface.
  • Your isolation is an illusion. The DO_NOT_TRUST you set on a child gets overridden by the parent, and your fine-grained intent silently fails โ€” you think it's locked, but the door is open.

What to do insteadโ€‹

Grant trust at the narrowest scope, and keep "untrusted things" physically outside any trusted parent.

  1. Don't "trust parent folder" on a directory that holds unfamiliar children. Any directory you clone or download third-party code into (~/projects, ~/Downloads) shouldn't be trusted wholesale; trust the specific project directory that's actually yours.
  2. Open unfamiliar / cloned repos from an isolated path. Give them a "quarantine" location outside any trusted parent, so Gemini asks you about trust on first open and keeps the call in your hands.
  3. Require explicit trust in CI; don't rely on auto. Declare it with GEMINI_TRUST_WORKSPACE=true / --skip-trust, and upgrade to โ‰ฅ v0.39.1; treat the "trust boundary" as a configuration you verify, not a default.
  4. Review ~/.gemini/trustedFolders.json periodically. Prune over-broad, stale entries โ€” trust expires, but the file won't clean itself.

Exampleโ€‹

Before:

~/.gemini/trustedFolders.json
  "~/projects": "TRUST_FOLDER"        # "trust parent folder," picked earlier to save clicks

# later
$ git clone https://github.com/somebody/unknown ~/projects/unknown
$ cd ~/projects/unknown && gemini "take a look at this"
โ†’ inherits the parent's trust: unknown's .gemini/settings.json applies, .env is read, prompts ease up
โ†’ an injection hidden in the README now has a trusted context to land in

After:

# clone into a quarantine path outside any trusted parent
$ git clone https://github.com/somebody/unknown ~/quarantine/unknown
$ cd ~/quarantine/unknown && gemini "take a look at this"
โ†’ Gemini asks: trust this folder? [No]
โ†’ untrusted = safe mode: its settings.json / .env are ignored, read at the least-privileged posture

The difference isn't that I got more vigilant โ€” it's that the "trust or not" switch was granted at the right, narrowest scope, instead of flipped wide open days ago for something unrelated.

When the exception appliesโ€‹

If it's a monorepo that's all your own code, where every subdirectory is yours and should be trusted, trusting the parent is reasonable and saves repeated prompts. This entry is about mixed trees โ€” your code sitting alongside untrusted clones and third-party directories under one parent. The test is simple: will this parent folder ever come to hold code "you didn't write and haven't read"? If yes, don't trust it wholesale.

Version notesโ€‹

Applicability

The Trusted Folders mechanism and safe-mode behavior are in the official trusted-folders docs (as of 2026-06). The CI/headless auto-trust of the workspace was fixed in v0.39.1 to require explicit trust (GHSA-wpqr-6v78-jr5g). "A parent's TRUST overriding a child's DO_NOT_TRUST" is a community report (issue #13125) whose status may change with fixes โ€” before you act, defer to that issue and your version's current behavior.

Further reading and sourcesโ€‹