There is a strange habit in AI tooling where people will spend a lot of time talking about alignment, prompt design, and agent reasoning, and almost no time talking about the environment the agent is actually running in.

That is backwards.

If the workflow can write files, execute commands, route across repositories, and operate unattended, then runtime isolation is not a nice extra. It is part of the safety model.

That is why sandboxed execution matters so much in the new limerIQ.

The Basic Principle

The core idea is simple:

if a workflow is doing meaningful work, it should be able to do that work in an isolated environment per worktree.

In limerIQ, that means the runtime can re-exec the workflow inside a sandboxed container environment and keep the execution scoped to mounted paths instead of giving the run ambient access to the host machine.

Today that sandbox runtime can use Docker or Apple Container, depending on the machine and configuration.

That matters because it moves isolation from a policy aspiration to a concrete runtime boundary.

Per-Worktree Isolation Is the Right Shape

The sandbox feature is intentionally tied to worktree execution.

That is important. The goal is not just "put AI in a container." The goal is to isolate the specific run, in the specific workspace, with the specific mounted paths it actually needs.

That has a few practical benefits:

• each sandboxed run stays self-contained
• workflow state can live with the worktree instead of bleeding across runs
• retries and resumes stay attached to the correct workspace
• the blast radius is reduced when a workflow is touching more than one repo

This is also why the sandbox system pairs well with Threads. The thread decides what execution context exists. The sandbox decides how tightly that context is isolated at runtime.

Authentication Is the Annoying Part, So We Solved It

One reason sandboxing often gets hand-waved in developer tools is that credential flow gets messy quickly.

Provider CLIs expect to find their auth and config in real user home directories. Containers do not have your real home directory. The naive solution is to file-share a bunch of host paths into the container and hope nobody notices the security story collapsing.

We did not want that.

So limerIQ mirrors provider auth and configuration into a controlled staging home under ~/.limerIQ/sandbox/home/, then mounts that staged environment into the sandbox.

That gives the runtime what it needs without requiring the sandbox to reach directly into ~/.claude, ~/.codex, ~/.gemini, or the rest of the host environment.

This is a practical feature, but it is also a governance feature. Isolation does not count for much if the setup path quietly reintroduces the whole host machine.

Retry Without Restarting the World

Another detail we cared about is remediation.

Sandbox auth failures are annoying enough even when a human is watching. They are much worse when the product response is "start over."

limerIQ handles this with a worktree-local env bridge under .orchestrator/sandbox/env-dir. The runtime can update the sandbox-facing environment for the current worktree and retry the step without forcing a full restart of the workflow.

That may sound small, but it is the difference between a system people will actually use and one they avoid because the repair loop is miserable.

Good safety features should not be allergic to recovery.

The Runtime Should Fail Safe

There is another principle here that matters just as much as the sandbox itself:

if sandboxing is required and the runtime is unavailable, the system should not quietly pretend everything is fine.

limerIQ can detect whether a supported runtime exists and whether it is healthy. If the configured isolation path is unavailable, the product can fail clearly instead of silently degrading into unsandboxed execution.

There is an explicit path for dangerous fallback when someone really wants it. That is exactly how it should be. Unsafe fallback should be opt-in, not the surprise default.

Isolation Is Part of the Product Story Now

The reason this feature belongs in the new limerIQ story is that it changes what kind of claim the product can make.

It is one thing to say:

"We orchestrate coding agents."

It is another to say:

"We can run governed workflows in isolated environments, with controlled mounts, provider auth handling, retryable remediation, and clear runtime boundaries."

That second sentence sounds heavier because it is heavier. It carries real operational weight.

And that is the whole point of the relaunch. limerIQ is moving closer to delivery infrastructure and further away from prompt ergonomics as the center of the story.

Sandboxing is one of the clearest examples of that shift.

This Is About Trust, Not Theater

There is always a temptation to make safety features sound dramatic.

The real value here is more practical than dramatic.

Sandboxed execution helps teams answer ordinary but important questions:

• what could this run actually touch?
• where did it execute?
• how isolated was it from the rest of the machine?
• how do we retry a broken auth path without manually rebuilding everything?

Those are the questions that come up when a workflow leaves the comfort of a supervised desktop session and starts participating in real delivery work.

That is why this feature matters.

Not because "containerized AI" sounds futuristic.

Because if you want governed execution, the environment has to be governed too.