termic.dev
Documentation menu

The network allowlist

How Termic's sandbox confines an agent's network access to a per-task hostname allowlist via an in-process proxy, what's allowed by default, how to add hosts, and how to debug a blocked request.

Locking down the filesystem isn’t enough on its own. An agent that can’t read ~/.ssh but can open arbitrary connections could still POST your source to a server, or pull a payload from one. So the second half of the sandbox is a default-deny network policy: the agent can only reach hosts you’ve explicitly allowed.

How it works

Each sandboxed task gets its own HTTPS CONNECT proxy, and it runs inside the Termic binary, as a Rust thread on an OS-assigned free port. There’s nothing extra to install or keep running.

It works in two layers:

  1. The Seatbelt filesystem profile denies all network access except loopback to that proxy’s port. The agent cannot open a socket to the outside world directly.
  2. The proxy inspects the target hostname of every CONNECT and checks it against an allowlist. A match is forwarded; anything else gets an HTTP 403 and never connects.

This network layer applies only when the task runs in Enforcing (filesystem + network) mode, or in Monitoring (where it logs and classifies). The other enforcing mode, Enforcing (filesystem only) (see the Sandbox overview), turns the network sandbox off entirely: no in-process proxy runs, and the hostname allowlist on this page does not apply, so the agent reaches any host directly.

What’s allowed by default

The baseline allowlist is built into Termic per CLI, so the things an agent legitimately needs work without any configuration:

  • Vendor APIs, matched to the agent: anthropic for Claude, google for Antigravity, openai for Codex. The baseline also covers the hosts and self-update endpoints that GitHub Copilot, Grok, and Antigravity (agy) need out of the box.
  • GitHub, for cloning, pulling and the gh CLI.
  • Package registries: npm, PyPI, crates.io.
  • CA OCSP endpoints, so TLS certificate validation works.

These defaults are shown read-only in the sandbox dialog (under a “Built-in defaults” disclosure) so you can see what’s covered without having to retype any of it in your own config.

Adding your own hosts

When your project needs a host the baseline doesn’t cover, a private package registry, an internal API, a staging environment, you add it per project. The allowlist matches by hostname (* is a wildcard, regex under the hood), so you can be as specific or as broad as you need.

The right place to put these is .termic.yaml, committed to your repo. That way a teammate who opens the project inherits the same allowlist instead of hitting a wall of mysterious 403s and rediscovering each host by hand.

A host that belongs to an agent rather than a single project, your company’s API that every Claude task needs, goes in Settings → Agents → Sandbox allowed hosts instead, and applies to every task that runs that agent. This is also where the activity popover saves a host when you allow it “per agent”.

Watch first with Monitoring mode

You don’t have to discover hosts by hitting 403s. In the sandbox’s Monitoring mode nothing is blocked, but Termic still routes HTTP and HTTPS through the loopback proxy and logs every host the agent reaches, flagging the ones an Enforcing sandbox would have denied. Run a session in Monitoring, click the flagged hosts you recognize into the allowlist, then switch to Enforcing with the list already complete. (Non-HTTP traffic goes direct in Monitoring, so git-over-SSH and the like aren’t logged but also never break.)

When something is blocked

A sandbox denial is often silent. An npm install that can’t reach your private registry doesn’t always say “blocked”; it just fails in a confusing way.

The sandbox dialog has a recent denials panel. It reads the macOS system log for the last few minutes, filtered to this task’s path and to lines that record a denial, and shows you what the sandbox blocked. When an install or a fetch fails inside a sandboxed task, this is the fastest way to find the host or path you need to allow.

The sandbox does not flag common shell startup files (oh-my-zsh, prezto, fish), so sandboxed agents need less manual allow-listing to start.

Termic's recent-denials panel listing a blocked host (my-api.simion.cv) and a column of blocked filesystem paths, each with an Allow button, while the agent in the terminal explains the 403 returned by the sandbox proxy.

The denials panel names what the cage blocked: the host and each filesystem path, every one with a one-click Allow. The agent’s own output (left) shows it hitting the 403 at the proxy.

A practical workflow

  1. Start with the sandbox on and the defaults.
  2. If something fails, open the recent-denials panel and read what was blocked.
  3. Add the host (or path) to the project’s allowlist.
  4. Save. Editing the sandbox restarts the agent under the new profile (see why), and the next attempt goes through.
  5. Once it’s stable, commit the allowlist to .termic.yaml so the rest of the team gets it too.

On the roadmap

Today the proxy handles HTTPS CONNECT, which is what most agent traffic uses. Allowing raw TCP for things like a direct MySQL connection is a planned extension.

Last reviewed: June 25, 2026