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]>
2.0 KiB
Platform sandboxing details
The mechanism Code uses to enforce sandboxing varies by OS.
macOS 12+
- Uses Apple Seatbelt via
sandbox-execwith a profile that matches the selected--sandboxmode.
Linux
- Uses Landlock plus seccomp to apply the configured sandbox policy.
- In containerized environments (e.g., Docker) the host must support these APIs. If it does not, configure the container to provide the isolation you need and run Code with
--sandbox danger-full-access(or--dangerously-bypass-approvals-and-sandbox) inside that container instead.
Windows
Code launches commands with a restricted Windows token and an allowlist tied to declared workspace roots. Writes are blocked outside those roots (and %TEMP% when workspace-write is requested); common escape vectors like alternate data streams, UNC paths, and device handles are proactively denied. The CLI also inserts stub executables (for example, wrapping ssh) ahead of the host PATH to intercept risky tools before they escape the sandbox.
Known limitations (smoketests)
Running python windows-sandbox-rs/sandbox_smoketests.py with full filesystem and network access currently passes 37/41 cases. The remaining high-value gaps are:
| Test | Purpose |
|---|---|
| ADS write denied (#32) | Alternate data streams can still be written inside the workspace (should be blocked). |
| Protected path case-variation denied (#33) | .GiT bypasses protections meant for .git. Case variants should be rejected. |
| PATH stub bypass denied (#35) | A workspace ssh.bat shim placed first on PATH is not reliably executed, so interception cannot be proven. |
| Start-Process https denied (#41) | Start-Process 'https://…' succeeds in read-only runs because Explorer handles the ShellExecute outside the sandbox. |
How to help
If you can iterate on Windows sandboxing, aim to close the four smoketest failures above and rerun python windows-sandbox-rs/sandbox_smoketests.py until all 41/41 pass.