Tool Tips · For engineers

Gemini CLI 0.65.0 won't rewrite an untrusted repo's settings.

From 0.65.0, Gemini CLI won't write a repo's settings file in an untrusted folder. What the fix covers, what was already true, and what to check.

30 Oct 2026 · 5 min read · sources read up to 30 Oct 2026

You just cloned a repo you don't know

Gemini CLI 0.65.0 protects a repo's settings file from your own Gemini CLI commands when the folder is untrusted ^[3]. It doesn't protect you from the repo, and that part was already in place ^[7].

Say someone sends you a link, you clone the repo, and you open it in Gemini CLI, Google's open-source AI coding agent for your terminal ^[1]. You haven't told the tool to trust the folder. It's an example we made up, but you probably know the feeling: before you type anything, a small nagging question shows up. What can this folder change, and what can the tool I'm running in it change?

Gemini CLI 0.65.0 came out on 20 October 2026, and the first item in its release notes is "fix(cli): enforce read-only workspace settings in untrusted folders" ^[2]. That sounds like big news, and it is easy to take it as bigger than it is. So we went to the pull request, the issue behind it and the code ^[3][4][5].

What "read-only" covers

A repo can carry its own Gemini CLI settings, in a file called .gemini/settings.json inside the project. Those are the workspace settings ^[3]. Your own settings, the ones that go with you into every folder, are the user-level settings (the error message below calls them the global settings file). An untrusted folder is one you told Gemini CLI not to trust, or one you haven't decided on yet ^[7][9].

Since 0.65.0, in an untrusted folder the workspace settings file is read-only: Gemini CLI won't write to it ^[3]. The pull request names two commands, gemini mcp add and gemini mcp remove. They add and remove MCP servers, the add-ons that give the AI extra tools ^[3]. Instead of writing, they now stop with an error. Adding to your user-level settings with --scope user still works ^[3].

The error reads "Cannot modify settings in an untrusted workspace." It then points to the way out: verify the source of the repository and set GEMINI_CLI_TRUST_WORKSPACE=true, or move your configuration to the global settings file, meaning your user-level settings ^[5]. The command exits with code 1 ^[6]. In the code, the untrusted workspace is marked readOnly: true, and it becomes writable again once you trust the folder ^[5].

The bug behind it

The fix came from a bug report, seen on version 0.60.0 and on a 0.62.0 nightly build. Running mcp add in an untrusted folder printed success, and afterwards the settings file held only the new entry. Every other setting was gone ^[4]. The same command in a trusted folder kept everything ^[4].

That is the kind of bug you meet weeks later, when a setting you remember isn't there and nothing ever told you. The issue reports the silent part: success printed, settings gone ^[4].

What was already true

The fix protects the repo's settings file from your own commands. It is not new protection of you from the repo, and that part was already in place. Google's Trusted Folders page, last updated on 23 April 2026, lists what an untrusted folder already does ^[7]:

• It doesn't load the project's settings file ^[7].
• It doesn't load .env files ^[7].
• It doesn't run MCP servers or custom commands from the project ^[7].
• It always asks before tools run ^[7].

So 0.65.0 closes the other direction. The repo's settings were already ignored, and now your own commands can't overwrite them either ^[3][7]. We only know that for the two commands the pull request names. We didn't read whether other routes, such as the /settings dialog, are covered ^[3].

None of this makes opening a stranger's repo safe, and nobody we read says it does. We'd call it read-only and leave it there.

Check the state before you rely on it

The first time you open a folder, Gemini CLI asks whether to trust it. Four things are worth knowing about that question ^[7]:

• The prompt offers three answers: Trust folder, Trust parent folder, or Don't trust.
• Your answer is saved in ~/.gemini/trustedFolders.json, and the /permissions command changes it.
• If an IDE is connected, its answer wins.
• Headless runs, where no one is at the keyboard, exit with an error unless --skip-trust or GEMINI_CLI_TRUST_WORKSPACE=true is set.

Those last two settings skip the question, so keep them for a repo whose source you have verified. That is the condition the error message itself gives ^[5].

One wrinkle. Google's docs page says the Trusted Folders feature is "disabled by default" ^[7]. The 0.65.0 code says otherwise: security.folderTrust.enabled defaults to true, and a folder with no saved decision loads as untrusted ^[8][9]. So we won't state a default. Run /permissions and read what it says.

What we'd do

1. Update Gemini CLI. Version 0.65.0 has this guard. The next release, 0.66.0 (27 October), doesn't change how folder trust works, so 0.65.0 or newer is enough ^[2][10].
2. Open the cloned repo and run /permissions. Read the state before you let the tool act on anything.
3. For a repo you don't know, choose Don't trust ^[7].
4. If you see "Cannot modify settings in an untrusted workspace", read the whole message before you override anything ^[5].
5. Keep your own tool setup in your user-level settings with --scope user, not in someone else's repo ^[3].

Before you go and install it

Gemini CLI is now aimed at Google's paid enterprise plans and paid API keys. Free and Google AI Pro and Ultra access moved to Antigravity CLI, a different Google command-line tool, on 18 June 2026 ^[11][12][13]. Nothing here is a claim about how Antigravity CLI handles folder trust. Gemini CLI itself is Apache-2.0 open source ^[1].

How we checked

We haven't run any of this ourselves. Everything above comes from Google's own pages and code, which we read on 30 October 2026: the 0.65.0 release page, the pull request and the issue behind it, the source files at the 0.65.0 tag (read, not built), the Trusted Folders page, and the README and blog post about the plan change ^{[2][3][4][5][6][7][8][9][11][13]}. The issue's reproduction needs no sign-in, so a throwaway folder could test it, and nobody here has. That is why this page says read-only and never safe.

zenlite is independent of Google. We researched and drafted this with AI assistance, and a human checked it.