Nix OpenCode With MITM

Checked: 2026-07-14

Project Summary

Nix OpenCode With MITM is a small Nix flake that runs OpenCode inside a Linux namespace jail with no direct network. Approved outbound HTTP and HTTPS traffic is tunneled through a host-side mitmproxy over a Unix socket.

• Repository name: nix-opencode-with-mitm
• README title: myjailedagents
• Implementation: One Nix flake plus documentation
• Agent: OpenCode only
• Status: Proof of concept; the author says it is not near production-ready
• License: No license file or declared repository license was found

Problem Solved

A locally running coding agent normally inherits broad access to the host filesystem, network, and credentials. A basic filesystem jail can hide most host files, but the agent still needs selected internet services.

This project tries to combine:

• a narrow filesystem/process jail;
• no direct network namespace access;
• an external proxy that allows only configured hosts;
• TLS interception so HTTPS follows the same host policy.

How It Works

1. Nix builds a pinned set of OpenCode, jail.nix, ip2unix, Tinyproxy, mitmproxy, and command-line tools.
2. jail.nix creates a namespace-based process jail.
3. The jail receives the current working directory and OpenCode configuration/state paths as read-write mounts.
4. The jail has no normal network namespace access.
5. A host wrapper starts mitmdump outside the jail and listens through a Unix socket.
6. Inside the jail, Tinyproxy and ip2unix translate normal HTTP proxy traffic to that mounted socket.
7. The host proxy terminates TLS and rejects destinations outside MITM_ALLOW_HOSTS.
8. The wrapper pre-resolves approved names and writes a small /etc/hosts because the jail has no DNS.
9. Startup checks verify that direct internet access fails, an allowed host works through the proxy, and a disallowed host fails.

The main entrypoint is the Nix package opencode-with-mitm. The flake also exposes lower-level no-network and proxy-jail packages.

Security Boundary

• Compute boundary: Linux namespaces and bind mounts supplied by jail.nix, not a virtual machine.
• Kernel: The jailed agent shares the host Linux kernel.
• Network boundary: Unshared network namespace plus an explicitly mounted Unix socket to the host proxy.
• Filesystem boundary: Only Nix dependencies and explicit bind mounts are visible; the Nix store is intended to be read-only.
• Session restriction: The jail uses a no-new-session combinator.

The project’s security report says it is not suitable for kernel-exploit defense, determined adversaries with root access, or multi-tenant use without more hardening. A jail.nix, kernel, namespace, bind-mount, ip2unix, or proxy flaw can weaken the boundary.

Platforms And Agents

• Host: Linux with Nix flakes and working user namespaces. The design depends on Linux namespaces, so macOS and Windows are not practical native hosts.
• Architectures: The flake uses the default Nix flake systems. Actual usability depends on Linux package support for all pinned inputs.
• Agent: OpenCode packaged by llm-agents.nix.
• Other agents: No Claude Code, Codex, Gemini, or generic-agent wrapper is implemented, though the Nix functions could be adapted.
• User experience: Command-line only; no daemon, editor integration, session manager, or remote control plane.

Setup And Workflow

1. Install Nix with flakes enabled on Linux.
2. Clone the repository.
3. Build the opencode-with-mitm flake output or run it directly with nix run.
4. Configure OpenCode in the host paths expected by the flake.
5. Run from the project directory that OpenCode should modify.
6. Set a space-separated host allowlist when more than the default models.dev destination is needed.

Debug output can expose proxy logs. A separate environment escape hatch disables the jail and runs OpenCode on the host while keeping proxy wrapping; the security report calls this a dangerous footgun.

Network And Credentials

Network

• Direct access: Intended to be impossible because the jail’s network namespace is unshared.
• Approved access: HTTP/HTTPS goes through Tinyproxy, ip2unix, a Unix socket, and host-side mitmproxy.
• Default allowlist: models.dev.
• DNS: Approved hosts are resolved before launch and written to the jail’s /etc/hosts; no normal DNS is available.
• TLS: mitmproxy generates a local certificate authority. Its certificate is copied into the jail and configured for OpenSSL and Node.js trust.
• Verification: Startup assertions check direct denial and allowlist behavior.

Important limits:

• This is host allowlisting, not request-path, method, body, or response policy.
• The fixed pre-resolved address can become stale or fail with complex content-delivery behavior.
• An approved host can receive any data the agent can read.
• TLS certificate pinning or clients that ignore the configured certificate store may fail.
• The proxy’s generated private key and configuration live in a fixed shared temporary path during execution.

Credentials

There is no external credential-injection system. The author said in Hacker News that outside-the-sandbox token injection is a desired feature.

OpenCode’s host configuration, data, and state directories are mounted read-write into the jail. The project’s own security report warns these paths may contain API keys and tokens, so the agent may read real credentials and alter state that affects future runs.

This means the proxy limits where a stolen token can be sent, but it does not keep the token secret from the agent. Data or credentials can still be exfiltrated to an allowed host.

Strengths

• Default-deny network design: The jail has no normal network path.
• Host allowlist: Only configured destinations pass through the proxy.
• TLS coverage: HTTPS is inspected rather than becoming an opaque tunnel.
• Defense in depth: Namespace isolation, Unix-socket-only access, proxy allowlisting, fixed DNS, and startup assertions overlap.
• Reproducible dependencies: Nix pins the toolchain and supporting packages.
• Small auditable surface: The implementation is mostly one Nix file.
• Honest threat report: The repository lists concrete findings, severity, impact, and recommended fixes.
• Useful experiment: Demonstrates how a jailed process can reach a host policy engine without receiving a general network interface.

Limits And Risks

• Not production-ready: Explicitly stated by the author.
• One-commit project: No follow-up development was visible after initial publication.
• Shared kernel: Namespace isolation is weaker than a VM against kernel exploits.
• Credentials exposed: Real OpenCode config/state is mounted read-write.
• Project exposed: Current working directory is mounted read-write; launching from the wrong directory can expose much more host data.
• Fixed shared temp path: /tmp/jailed-agents is predictable and writable, enabling denial of service and cross-run or cross-user interference.
• Persistent config manipulation: The agent can modify host OpenCode state and influence later runs.
• Unsafe bypass: OPENCODE_DISABLE_JAIL=1 silently changes the compute boundary to the host process path.
• Dev-shell trap: nix develop provides an unsandboxed OpenCode binary that can be mistaken for the jailed entrypoint.
• No secret broker: Tokens are visible inside the jail and are not scoped to individual requests.
• Allowlist only: No content-aware HTTP policy or protection from an approved server reflecting data.
• Limited compatibility: Only OpenCode and proxy-aware HTTP/TLS behavior are covered.
• No resource controls: No documented CPU, memory, process, or storage quotas.
• No license: Reuse and redistribution rights are unclear without a license grant.
• Documentation/code mismatch: A comment says the proxy jail has “no cwd mount,” but it assigns the common options that include mount-cwd; the security report correctly treats the working directory as mounted.

Activity And Maturity

• Repository created: 2026-03-31
• Latest push when checked: 2026-03-31
• Repository signal: 0 stars, 0 forks, 0 open issues, no releases, and no declared license in GitHub metadata
• Code size: A single roughly 19 KB Nix flake plus README, agent notes, lockfile, and security report
• Assessment: Research prototype only. Its design is useful for comparing network-control techniques, but the untouched security findings, fixed temporary path, visible credentials, bypasses, minimal adoption, and lack of releases make it unsuitable as a trusted daily sandbox without significant work.

Best Fit

The project best fits:

• Nix users studying namespace jails and host-side MITM proxying;
• a personal experiment with OpenCode and a very small service allowlist;
• developers willing to audit and harden the Nix implementation themselves;
• comparison research on network mediation without a VM.

It is a weak fit for production, hostile code, multiple users, macOS/Windows, many agents, general internet use, safely brokered credentials, or non-technical users.

Comparison-Relevant Facts

Fact	Nix OpenCode With MITM
Primary purpose	Experimental jailed OpenCode with allowlisted HTTPS
Compute boundary	Linux namespaces through jail.nix
Host support	Linux with Nix
Agent support	OpenCode only
Project access	Current working directory mounted read-write
Host config access	OpenCode config/data/state mounted read-write
Direct network	Disabled by namespace isolation
Approved network	Host allowlist through Tinyproxy, ip2unix, and mitmproxy
DNS	Pre-resolved allowlisted hosts in /etc/hosts
TLS inspection	Yes
Secret injection	Not implemented
Persistence	Host OpenCode config/state and project persist directly
Runtime bypass	Jail-disable environment variable and unsandboxed dev shell
Resource quotas	Not documented
License	None found

Hacker News Context

The project author posted it as a reply to a Nix/microVM sandbox comment. The author described it as something “vibecoded” with bwrap.nix, explicitly said it was nowhere near production-ready, and explained the goal: keep token injection outside the sandbox and control the network through an external MITM proxy.

The repository partially achieves that goal:

• Achieved: No direct network, host allowlist, and TLS mediation outside the jail.
• Not achieved: Real secret non-exposure. OpenCode’s host configuration/state is mounted inside, and the author names external token injection as future desire rather than current behavior.

The parent HN project used microvm.nix, which gives a VM boundary and richer Claude Code orchestration. This project instead uses a lighter shared-kernel jail and focuses on the network-proxy experiment.

Unknowns

• Exact jail implementation: The pinned jail.nix behavior was not independently audited in this research.
• Current OpenCode identity: The flake gets OpenCode through a pinned external package set; exact upstream version and project lineage were not resolved here.
• Proxy bypass coverage: Non-HTTP libraries, unusual Node network behavior, Unix-socket abuse, and protocol edge cases were not tested.
• Multi-architecture builds: No current continuous-integration evidence was found.
• Maintainer intent: No roadmap, release plan, or follow-up commits were found.

Sources

• Official repository
• README
• Nix implementation
• Security report and threat model
• GitHub repository metadata
• Hacker News Clawk thread
• HN project-author comment
• HN parent microVM/Nix comment