The Command Succeeded. The Sandbox Didn’t.

Dream.OS is supposed to let me say, “Run this task,” and then get a verified result back without becoming the human bridge between ChatGPT, Termux, CPC, GitHub, and the VPS.

That was the point of this lane. Not another planner. Not another agent story. A real path from an operator request to a governed worker that can claim work, execute it, verify it, and close it with evidence.

We got closer. We also found the line we cannot cross yet.

A command returning success is not the same thing as the sandbox existing.

The work moved from story to boundary

The recent Dream.OS posts established the direction: the swarm was becoming infrastructure, then a control plane, then something that needed to create external value. This session moved that story into a stricter runtime test.

DreamVault PR #83 adds the explicit task trigger. It turns a named operator request into the existing DreamVault assignment shape while preserving source authority, task identity, owner compatibility, and the selected worker. It refuses task substitution, stale authority, and execution holds.

Dream.os-Core PR #94 adds the admission side. It validates that assignment against a trusted local principal and owner-controlled configuration, then prepares an immutable packet for the existing DreamSync feed. It does not create a new queue, service, worker, or authentication system.

That matters because the system should not fake autonomy by routing every request to a coding worker. The commercial video pilot is a real outcome contract: one complete, independently reviewed 15–30 second spec ad. It is not an executable shell task. PR #94 correctly rejects it until there is a verified video-capable executor.

The first acceptance passed only part of the truth

On the VPS, the source boundary held. We created an isolated review worktree for PR #94, built a dedicated user-owned test environment, and left production Python alone. The source acceptance passed:

40 passed
HEAD=addffce96b13a6da66e22b2590dd32938094fa64
OUTCOME=SOURCE_ACCEPTANCE_PASS
LIVE_TASK_CLAIMED=NO
PRODUCTION_MUTATED=NO

That is a useful milestone. It proves the admission source and feed behavior at the exact PR head.

It still does not prove that Dream.OS can finish an operator-requested task.

The broader runtime suite collected 69 tests. Sixty-seven passed. Two skipped because the host could not create the required no-network namespace. The launcher refused to call that a pass:

67 passed, 2 skipped
OUTCOME=BLOCKED
REASON=REQUIRED_END_TO_END_PROOF_NOT_PASSED

That was the correct failure. The end-to-end proof depends on a worker sandbox that can execute without network access. If that boundary is not real, the worker cannot be trusted with autonomous execution.

The command succeeded. The namespace did not.

The focused diagnostic finally made the blocker concrete.

PARENT_NETWORK_NAMESPACE=net:[4026531840]
KERNEL_UNPRIVILEGED_USERNS_CLONE=1
USER_MAX_USER_NAMESPACES=31610
APPARMOR_RESTRICT_UNPRIVILEGED_USERNS=1
APPARMOR_CURRENT_PROFILE=unconfined

UNSHARE_RESULT:
  exit=1
  stderr=unshare: write failed /proc/self/uid_map:
         Operation not permitted

USER_SYSTEMD_RESULT:
  exit=0
  stdout=net:[4026531840]

OUTCOME=BLOCKED
REASON=BOTH_EXISTING_ISOLATION_PROVIDERS_FAILED

The unshare provider failed directly: UID mapping was denied. The user-systemd fallback was worse in a subtler way. It exited zero, but the process stayed in the parent network namespace.

If Dream.OS had trusted the command exit alone, it would have recorded a false security guarantee. The runtime’s namespace comparison caught that. It required the child namespace to differ from the parent namespace, and it refused to proceed when systemd returned success without isolation.

That is the most important result of the session. The system did not finish the task, but it also did not lie about being safe.

The candidate fix is narrow

The current fallback requests PrivateNetwork=yes and NoNewPrivileges=yes. The candidate correction is to also request PrivateUsers=yes:

"-p", "PrivateUsers=yes",
"-p", "PrivateNetwork=yes",
"-p", "NoNewPrivileges=yes",

That may give systemd the user namespace it needs before enforcing a private network namespace. It may still fail under the host’s AppArmor policy. That is why the validation launcher does not commit anything. It temporarily patches the review worktree, proves the namespace, runs only the two previously skipped tests, and restores the file afterward.

If it passes, the fix belongs in PR #94 with regression coverage for the false-success behavior. If it fails, the answer is not to disable isolation. The answer is to preserve the provider errors and choose a supported host isolation policy.

This advances the Dream.OS story

This is not the triumphant “Dream.OS is autonomous now” post. It is the chapter where the control plane meets the real operating system and refuses to fake success.

The story is moving:

• First, the swarm became more than a set of chat sessions.
• Then it became infrastructure with authority, receipts, and persistent state.
• Then it became a control plane instead of a model wrapper.
• Then the product question became external value, not internal elegance.
• Now the execution boundary is being forced to prove itself against the actual VPS.

The next chapter has to be a completed task. Not a draft PR. Not a packet. Not a queue entry. A request enters Dream.OS, the right worker claims it once, execution happens inside the approved scope, verification passes, and a durable receipt comes back.

That is the standard now.

I still want to say “Dream.OS, run this,” and get the outcome back. This incident shows why the system has to earn that sentence before I trust it.