Description
Gemini 3 models are fundamentally trained to operate as native bash users, chaining standard POSIX tools (grep, cat, sed, awk) to explore codebases and edit files. To make full use of the model's native and preferred capabilities without compromising user security or UX, we need to allow the model to use these tools directly to interact and make changes.
Prior Art
Historically, we have attempted to force models to use custom tools (such as replace, grep_search, write_file, etc.). However, these methods fight the model's core training. Malicious prompts or complex scripts are inherently hard to control and catch via parsing, and forcing custom tools creates significant downstream UX and security issues.
The Challenge & Value Proposition
Because the model strongly favors raw bash calls even when nudged towards custom tools, it frequently outputs large, complex bash scripts to accomplish tasks. Under our current security model, these scripts require explicit user confirmation.
This creates a critical point of failure: users are frequently presented with dense, hard-to-read bash messages to evaluate. This leads to severe prompt fatigue, causing users to either blindly confirm the execution or enter "yolo mode" (auto-approving all actions). This behavior is highly detrimental to security and degrades the overall user experience.
Value Proposition: By safely embracing the model's native bash tendencies, we can eliminate confirmation fatigue, prevent unsafe "yolo mode" habits, and drastically improve both the UX and our underlying security posture.
Proposed Solution
A highly viable solution is to utilize a secure sandbox. ALL standard shell commands will execute within a zero-dependency, kernel-enforced sandbox. Instead of trying to predict intent before execution (which led to the parsing challenges described above), we can safely observe and handle the results after execution.
Method
By running commands in a sandboxed replica of the workspace, we achieve three distinct UX lanes:
- Reads: Commands that do not mutate the filesystem (e.g.,
ls, grep) are auto-approved. We must ensure this does not read from protected spaces or outside our trusted workspaces.
- Edits: Commands that mutate the sandboxed filesystem (e.g.,
sed -i, >) trigger a post-execution Diff UI before the changes are synced back to the host, allowing for a seamless "Edit" tool experience using the model's preferred mechanisms.
- Side-Effects: A dynamic command router will handle commands requiring host credentials or network access (e.g.,
git, gh), completely bypassing the sandbox but requiring strict upfront user confirmation (i.e., stays the same as today, utilizing the policy engine to execute or ask for user confirmation).
Architectural Mandates
In order to support this properly, we must explore, investigate, and implement the proper sandboxing for all major platforms: Linux, macOS, and Windows.
Epic
This is an epic that tracks this investigation and implementation. It will contain subtasks used to track progress towards its overall completion. After initial investigation, if this is not a feasible route, the epic can be marked as closed.
Description
Gemini 3 models are fundamentally trained to operate as native bash users, chaining standard POSIX tools (
grep,cat,sed,awk) to explore codebases and edit files. To make full use of the model's native and preferred capabilities without compromising user security or UX, we need to allow the model to use these tools directly to interact and make changes.Prior Art
Historically, we have attempted to force models to use custom tools (such as
replace,grep_search,write_file, etc.). However, these methods fight the model's core training. Malicious prompts or complex scripts are inherently hard to control and catch via parsing, and forcing custom tools creates significant downstream UX and security issues.The Challenge & Value Proposition
Because the model strongly favors raw bash calls even when nudged towards custom tools, it frequently outputs large, complex bash scripts to accomplish tasks. Under our current security model, these scripts require explicit user confirmation.
This creates a critical point of failure: users are frequently presented with dense, hard-to-read bash messages to evaluate. This leads to severe prompt fatigue, causing users to either blindly confirm the execution or enter "yolo mode" (auto-approving all actions). This behavior is highly detrimental to security and degrades the overall user experience.
Value Proposition: By safely embracing the model's native bash tendencies, we can eliminate confirmation fatigue, prevent unsafe "yolo mode" habits, and drastically improve both the UX and our underlying security posture.
Proposed Solution
A highly viable solution is to utilize a secure sandbox. ALL standard shell commands will execute within a zero-dependency, kernel-enforced sandbox. Instead of trying to predict intent before execution (which led to the parsing challenges described above), we can safely observe and handle the results after execution.
Method
By running commands in a sandboxed replica of the workspace, we achieve three distinct UX lanes:
ls,grep) are auto-approved. We must ensure this does not read from protected spaces or outside our trusted workspaces.sed -i,>) trigger a post-execution Diff UI before the changes are synced back to the host, allowing for a seamless "Edit" tool experience using the model's preferred mechanisms.git,gh), completely bypassing the sandbox but requiring strict upfront user confirmation (i.e., stays the same as today, utilizing the policy engine to execute or ask for user confirmation).Architectural Mandates
In order to support this properly, we must explore, investigate, and implement the proper sandboxing for all major platforms: Linux, macOS, and Windows.
Epic
This is an epic that tracks this investigation and implementation. It will contain subtasks used to track progress towards its overall completion. After initial investigation, if this is not a feasible route, the epic can be marked as closed.