The most important agent failure may not look like a bad answer. It may look like a command running with the wrong workspace roots, a denied path that the reviewer cannot see, a long-running container killed when one session closes, or an old sandbox left behind after a process dies.
Yesterday's edition followed the user-facing control room: links, interrupts, session switching, and keyboard behavior. Today's source trail moves underneath that room. If agents are going to run real commands on real machines, the runtime has to know where the work is allowed to happen, what should survive, what should be cleaned up, and which container lifecycle commands deserve human approval.
Codex makes workspace roots explicit
OpenAI Codex commit 986c60467 changes the Windows sandbox path from a single runtime anchor toward explicit workspace roots. The commit says symbolic :workspace_roots entries need to be materialized for every effective root before the command runner chooses token mode or builds access-control plans.
The patch threads Config::effective_workspace_roots() through core execution, unified exec, TUI setup and read-grant flows, app-server setup, app-server command execution, and debug sandbox paths on Windows. It also updates elevated runner IPC to carry workspace_roots and adds resolver coverage for exact and glob workspace-root entries across multiple roots.
That is not a flashy model feature. It is a boundary feature. A multi-root agent session cannot safely treat "the workspace" as whatever the current directory happens to be. The runtime has to carry the roots as data.
The filesystem policy enters the prompt context
A companion Codex commit, e7dda807, makes the same pressure visible to the model and approval reviewer. The commit says legacy sandbox summaries could omit permission-profile filesystem entries from escalation decisions, including denied reads under workspace roots.
The new environment context renders the effective filesystem profile, workspace roots, and non-escalatable deny entries. It also persists effective workspace roots in turn context and passes the parent turn's denied-read context into automatic approval reviews.
The article should not oversell that as full security. The narrower source-grounded claim is stronger: Codex is turning filesystem policy into explicit context so the model and review path can reason about active limits instead of inferring them from a coarse sandbox label.
Hermes treats Docker containers as session state
NousResearch Hermes Agent shows the same maturity pressure from the container side. Commit ac8e238b says the Docker backend docs promised one long-lived container shared across sessions, new tasks, resets, and delegated subagents, but the code only honored that contract inside one Python process.
The fix adds cross-process container discovery using Hermes labels, reuses running or stopped matching containers, replaces racy detached-shell cleanup with a thread that uses bounded subprocess.run, adds wait_for_cleanup, and wires a new terminal.docker_persist_across_processes setting.
Commit 5c2170a7 tightens the semantics further: in persist mode, cleanup becomes a no-op for the container, so background processes and filesystem state can survive session cleanup. Explicit teardown still exists through force_remove=True. Commit 2f0f03c4 then corrects cleanup_vm() so a TUI or gateway session close honors persist mode instead of killing a shared container by default.
This is where the abstraction becomes practical. If an agent is running tests, watchers, servers, or delegated work inside a container, "session closed" and "destroy the machine" cannot be the same event unless the user asked for that.
Cleanup has to cover the ugly exits
Containers also fail messily. Hermes commit d77d8776 adds a startup orphan reaper for containers left behind when normal cleanup cannot run. The commit specifically names SIGKILL, OOM kill, and terminal-window close as exits where atexit handlers do not fire.
The implementation described in the commit filters for Hermes-labeled exited containers, optionally scopes by profile, inspects finish times, removes old candidates, and continues after individual failures. It is deliberately conservative about running containers because those may belong to another Hermes process.
That caveat is the story. Cleanup is no longer just "delete the old thing." It has to know which environment is abandoned, which one might still be in use, which profile it belongs to, and how old is old enough.
Some Docker commands become approval events
The clearest reader-facing boundary appears in Hermes commit 54bf7987. It adds docker restart, docker stop, docker kill, and Docker Compose lifecycle commands to dangerous approval patterns.
The commit message gives the reason: when docker.sock is mounted, an agent can restart, stop, or kill containers without user approval. Hermes already protected gateway restart, but not the Docker forms. The observed failure was a self-termination loop: the agent restarted the Hermes container, Docker restarted it, and the resumed session repeated the same action.
That is the whole pattern in one bug. Once an agent has a machine, the runtime has to decide which machine operations are ordinary work and which ones are control-plane actions that need a human checkpoint.
The machine boundary is becoming part of trust
None of these commits prove a shared standard. They do not prove that sandboxes are solved. Codex and Hermes are different projects with different architecture. But the independent movement is still visible: local execution assumptions are being pulled into named roots, rendered policies, cleanup modes, reaper rules, and approval patterns.
That is how agent trust becomes less magical. Not by assuming the model will remember every boundary, and not by hiding the machine behind a friendly chat. Trust improves when the runtime can say: these are the workspace roots; these paths are denied; this container should survive; this orphan is safe to reap; this Docker command can kill the room and needs approval.
The next thing to watch is whether these machine-boundary contracts become inspectable product surfaces. The control room needs buttons, but it also needs a floor plan: what machine the agent is using, what it can touch, what is still running, and what cleanup will actually do.