zeekayandHanzo Dev
6cbbea2d03
Our history is just-every's with author emails rewritten, so the graphs are
disjoint and git finds no merge base. Supplied one by hand: d1f1f51a41, the
just-every commit matching our Oct-2025 fork point (22 files apart). 9618
upstream commits, 7004 files, +1.81M/-159k, 37 conflicts.
Resolution:
- Upstream code where our side was the Oct-2025 prototype of a feature they
have since reimplemented 3-5x larger (agent_runs, browser_sessions,
history_cell/{agent,browser}, the vt100 harness and its snapshots).
- Upstream's config.rs module split (builder/defaults/sources/validation)
kept; zen5-coder and the provider-follows-model rule re-applied on top.
- Ours where the file IS the identity: README, package.json, postinstall,
release notes pipeline, integration-zed.
- Hybrid where upstream improved a file we had branded: updates.rs (their
release-repo migration, our hanzoai/dev), release.yml (their fail-fast npm
auth check, our package name), chatwidget.rs (their turn handling, our
HANZO_USER_KEY hint), exec human output (their 237 lines, our banner).
Superseded and dropped deliberately: our resume_command_name() coder-alias
hack — upstream's derive_resume_command_name() reads the invocation basename
generically, which yields "dev" for us.
LLM.md now records the real topology and the sync point; AGENTS.md and
CLAUDE.md are symlinks to it again. Single parent on purpose: adopting
jecode/main as a second parent would re-import 13,742 commits carrying the
upstream author emails a prior rewrite deliberately removed.
Version 0.2.188 -> 0.2.189.
Co-authored-by: Hanzo Dev <[email protected]>
5.5 KiB
Sandbox & approvals
Approval modes
We've chosen a powerful default for how Code works on your computer: Auto. In this approval mode, Code can read files, make edits, and run commands in the working directory automatically. However, Code will need your approval to work outside the working directory or access network.
When you just want to chat, or if you want to plan before diving in, you can switch to Read Only mode with the /approvals command.
If you need Code to read files, make edits, and run commands with network access, without approval, you can use Full Access. Exercise caution before doing so.
Defaults and recommendations
- Code runs in a sandbox by default with strong guardrails: it prevents editing files outside the workspace and blocks network access unless enabled.
- On launch, Code detects whether the folder is version-controlled and recommends:
- Version-controlled folders:
Auto(workspace write + on-request approvals) - Non-version-controlled folders:
Read Only
- Version-controlled folders:
- The workspace includes the current directory and temporary directories like
/tmp. Use the/statuscommand to see which directories are in the workspace. - You can set these explicitly:
code --sandbox workspace-write --ask-for-approval on-requestcode --sandbox read-only --ask-for-approval on-request
Can I run without ANY approvals?
Yes, you can disable all approval prompts with --ask-for-approval never. This option works with all --sandbox modes, so you still have full control over Code's level of autonomy. It will make its best attempt with whatever constraints you provide.
Common sandbox + approvals combinations
| Intent | Flags | Effect |
|---|---|---|
| Safe read-only browsing | --sandbox read-only --ask-for-approval on-request |
Code can read files and answer questions. Code requires approval to make edits, run commands, or access network. |
| Read-only non-interactive (CI) | --sandbox read-only --ask-for-approval never |
Reads only; never escalates |
| Let it edit the repo, ask if risky | --sandbox workspace-write --ask-for-approval on-request |
Code can read files, make edits, and run commands in the workspace. Code requires approval for actions outside the workspace or for network access. |
| Auto (preset) | --full-auto (equivalent to --sandbox workspace-write + --ask-for-approval on-failure) |
Code can read files, make edits, and run commands in the workspace. Code requires approval when a sandboxed command fails or needs escalation. |
| YOLO (not recommended) | --dangerously-bypass-approvals-and-sandbox (alias: --yolo) |
No sandbox; no prompts |
Note: In
workspace-write, network is disabled by default unless enabled in config ([sandbox_workspace_write].network_access = true).
Fine-tuning in config.toml
# approval mode
approval_policy = "untrusted"
sandbox_mode = "read-only"
# full-auto mode
approval_policy = "on-request"
sandbox_mode = "workspace-write"
# Optional: allow network in workspace-write mode
[sandbox_workspace_write]
network_access = true
You can also save presets as profiles:
[profiles.full_auto]
approval_policy = "on-request"
sandbox_mode = "workspace-write"
[profiles.readonly_quiet]
approval_policy = "never"
sandbox_mode = "read-only"
Experimenting with the Code Sandbox
To test to see what happens when a command is run under the sandbox provided by Code, we provide the following subcommands in the CLI:
# macOS
code sandbox macos [--full-auto] [COMMAND]...
# Linux
code sandbox linux [--full-auto] [COMMAND]...
# Legacy aliases
code debug seatbelt [--full-auto] [COMMAND]...
code debug landlock [--full-auto] [COMMAND]...
Platform sandboxing details
The mechanism Code uses to implement the sandbox policy depends on your OS:
- macOS 12+ uses Apple Seatbelt and runs commands using
sandbox-execwith a profile (-p) that corresponds to the--sandboxthat was specified. - Linux uses a combination of Landlock/seccomp APIs to enforce the
sandboxconfiguration.
Note that when running Linux in a containerized environment such as Docker, sandboxing may not work if the host/container configuration does not support the necessary Landlock/seccomp APIs. In such cases, we recommend configuring your Docker container so that it provides the sandbox guarantees you are looking for and then running code with --sandbox danger-full-access (or, more simply, the --dangerously-bypass-approvals-and-sandbox flag) within your container.