Independent developer guide. Not affiliated with HarnessRouter or the official UHP project.

Remote harness execution and sandbox trust boundaries

Running an agent harness against a remote terminal, shared desktop or remote harness process creates trust boundaries that do not exist in a single-process local loop. This guide separates control-plane identity, remote environment state, human-versus-agent control, secret forwarding, artifact egress and session ownership from UHP's external task contract.

Page reviewed 4 Oct 2026 Source and review policy

Case-study protocol scope: 2026-09-12Pattern: implementation-level

Short answer

Remote harness execution is the descriptive label this guide uses when the agent control loop, terminal/sandbox, or child harness process runs across a host boundary rather than entirely inside one local process/filesystem. It is not a UHP, ACP, MCP or A2A protocol term.

When a human can take over the same remote desktop or browser state that the agent drives, control ownership becomes a separate trust boundary. The system must decide who is allowed to act now, fence in-flight agent actions across ownership changes, preserve useful session state without permitting simultaneous control, and fail closed when control state is ambiguous.

The important architectural change is that execution now crosses several independently meaningful trust boundaries:

Client / product
      │
      │ UHP (optional external contract)
      ▼
Harness / gateway host
      │
      ├── profile + session ownership
      ├── credential / environment policy
      │
      │ SSH / remote runtime / child-harness transport
      ▼
Remote execution environment
      │
      ├── command execution
      ├── working files
      └── produced artifacts
             │
             │ validated egress / fetch
             ▼
        host-side delivery

A system can get the protocol request right and still get the remote-execution boundary wrong. Environment variables can be missing or leak across profiles, an artifact path can resolve to a credential store, a symlink can cross an intended boundary, a shared process cache can silently select the wrong terminal backend, a repeatedly reloaded environment can grow from its own prior writes, a state database can use locking semantics that the underlying host↔VM filesystem cannot safely provide, or a human takeover can race an already-admitted computer/browser action.

Trace a missing artifact through both directions of trust

If the agent reports a file but the client cannot download it, do not immediately rerun the producing task. The file may exist remotely while host egress, registration or delivery failed. The Hermes remote delivery and control evidence is one source-pinned example of independently owned remote state; it is not a universal remote-execution contract.

Identify the execution owner, remote runtime generation and resolved workspace from the original task.
Inspect the remote file through that owner’s supported read path. Confirm a regular file, canonical location and bounded size; inspect symlinks and credential-store exclusions separately.
Check egress independently: which bytes crossed back, and do their digest/size match the intended artifact?
Check host registration and authorization separately from byte transfer. A fetched file is not yet proof of a permitted downloadable session artifact.
Reconcile delivery using the original artifact identity. Regenerate only when production is proven incomplete and another execution is authorized.

remote file → bounded validated egress → host artifact → authorized delivery

The same diagnostic separates missing SendEnv admission from missing remote AcceptEnv: a local allowlist alone cannot establish that a variable arrived. Use inert sentinel values, never production secrets, when examining the transport.

Pair this workflow with managed-runtime attestation when an endpoint may belong to a replacement worker, and session recovery when production or delivery status is uncertain.

Why this deserves a separate architecture layer

A local harness often has one process environment, one filesystem namespace and one obvious session owner. Remote execution breaks that assumption. The control host must decide what state may cross outward, while artifact delivery must separately decide what bytes may cross back and a shared interactive surface must decide who may act on it now.

That produces seven recurring concerns:

Boundary	Question
Execution ownership	Which profile/session owns this remote environment?
Environment transport	Which variable names and values may cross to the remote process?
Secret isolation	Which provider or platform credentials must never cross?
Artifact egress	Which remote files may be copied back and delivered?
Canonicalization/lifetime	Which resolved path, active sandbox and current session are authoritative?
State-store filesystem	Does the journal/locking mode match the actual coherence guarantees of the host↔VM storage path?
Interactive control	If a human and agent share a GUI/browser state, which actor holds the exclusive right to drive it?

These concerns are orthogonal to whether the outer client speaks UHP. UHP 2026-09-12 standardizes the client/server/harness task contract; it does not prescribe SSH SendEnv, remote filesystem extraction, ControlMaster behavior, process-global environment caching, dotenv reload semantics, SQLite journal mode, noVNC/RFB control leases or a specific sandbox implementation.

Hermes: released remote boundaries plus interactive desktop handoff

Remote gateway OAuth: authentication headers must follow the real browser session

Hermes Desktop PR #110987, merged as 03b0c794 on 16 September 2026, fixes a remote-gateway authentication gap for deployments behind Cloudflare Access Service Auth. A fresh OAuth sign-in could fail even when the saved remote connection had the required service-token headers: the existing request-header hook was attached to Electron’s default session and could fall back to the older v1 config.remote, while the OAuth window runs in a partitioned session and current Connections data lives in the v2 registry. An already-authenticated browser session could mask the defect through existing cookies.

The correction installs the remote-header listener on each OAuth partition as well as the default session, applies the resolved headers to the initial /login loadURL, and resolves header sources from current registry Connections with the v1 remote block as fallback. When multiple configured base URLs could match, the longer base URL wins so a path-prefixed gateway is not shadowed by an origin-level sibling.

The same change closes a request-splitting surface in custom remote-header values. Header names were already constrained, but an embedded CR/LF could survive ordinary trimming. Hermes now strips CR/LF in the canonical header-value normalizer and again after safeStorage decryption, so every consumer — OAuth extraHeaders, request hooks, Electron network requests and connection tests — receives sanitized plaintext. Decrypted source collections are memoized against the existing connection-config and registry caches to avoid repeated keychain work on every subresource request.

Upstream reports 130/130 focused Electron connection/remote-header tests passing, clean typechecks, and 2,221 passing tests in the full Electron project with one pre-existing unrelated failure reproduced on the base branch. The PR did not claim a real Windows GUI end-to-end run, so that validation boundary remains explicit.

The reusable invariant is: remote authentication metadata belongs to the actual network-session and connection-identity path that emits the request. Persisting headers correctly is insufficient if an OAuth partition, redirect path or newer connection registry bypasses the resolver; decrypted header values also need canonical validation before they reach any request API.

SSH environment forwarding: names and values have different transport surfaces

Commit 7456081d fixes a gap where a skill could declare required_environment_variables, or an operator could configure terminal.env_passthrough, and the variables worked locally/Docker but were absent on the SSH host. Hermes now forwards allowed variable names with SSH SendEnv; the values ride in the SSH client’s own environment rather than being embedded in the remote bash -c command text.

The implementation keeps Hermes provider credentials behind the same passthrough blocklist, can fill an unset allowed value from the Hermes .env, and unsets profile-scoped names that are absent from the active profile. The remote SSH daemon must also be configured to AcceptEnv the forwarded names.

A subtle transport detail matters: an SSH ControlMaster only relays the SendEnv names it was started with. Hermes therefore uses a control socket keyed by the active forwarded-name set instead of assuming one multiplexed connection can safely carry every later environment shape. Upstream records a live SSH-daemon verification of that behavior.

The general invariant is: an allowlist is not enough unless the transport actually carries the allowed state, keeps secret values off weaker command-line surfaces, and preserves profile ownership under connection reuse.

Remote artifacts: egress is a separate validation step

Commit 70a64db5 adds a host-side recovery path for MEDIA:/path when the artifact exists inside a remote terminal environment rather than on the gateway filesystem. BaseEnvironment.fetch_file copies a regular file through the existing execution channel using marker-fenced base64. The read is bounded inside the remote environment before bytes are transferred; the current implementation caps this delivery path at 50 MiB, preventing an unbounded source such as /dev/zero from flooding host memory.

The remote path is checked before transfer, resolved inside the sandbox, copied into the host document cache and then passed through the normal host delivery validator. This preserves the existing MEDIA: interface instead of adding a second file-delivery tool.

Follow-up commit b499ab11 tightens that path:

an unresolvable readlink -f now fails closed instead of falling back to the unresolved name;
strict media-delivery mode does not perform the remote fetch, preserving its existing recency gate;
the active sandbox lookup uses the current HERMES_SESSION_ID rather than a looser session-key assumption; and
path normalization is aligned with the host-side MEDIA: parser.

The follow-up source identifies SSH, Daytona and Vercel as known-remote-home cases. Backends without a known remote home keep a conservative home-relative denylist rather than being treated as equivalent automatically. That distinction matters: remote artifact support should not be generalized beyond the runtime identity and path information the implementation can actually verify.

Conversation and credential stores are never ordinary artifacts

Commit 4139695c closes a separate exfiltration hole in media delivery. Before the fix, MEDIA:~/.hermes/state.db could pass the default delivery policy even though the database contains cross-session conversation history and can contain secrets pasted into chats. Its SQLite WAL/SHM sidecars are especially dangerous under recency-based trust because normal writes keep them fresh.

Hermes now denies delivery of the relevant SQLite stores and sidecars, legacy sessions/ transcripts, the copied browser-profile/ login/cookie store and named-board kanban.db stores, while deliberately leaving ordinary skills, logs, memories and agent-created artifacts deliverable.

This illustrates another invariant: artifact allowlisting must be evaluated against data sensitivity, not merely path reachability or file freshness. A file produced or reachable inside a harness home is not automatically a safe user-facing artifact.

Commit 2e24e06e fixed a cross-profile terminal-backend leak in a multiplex dashboard process. A request scoped to a secondary profile could cause that profile’s terminal.backend to be re-bridged into shared os.environ. In the documented failure shape, a launch profile configured for SSH retained its SSH host variables but acquired TERMINAL_ENV=local from a sibling profile, so commands silently executed locally.

The fix resolves the true process-level Hermes home with an override-immune helper before re-bridging terminal configuration. Per-request profile overrides can still scope request-local work, but they can no longer redefine the shared process’s launch profile while that shared environment is being refreshed.

The architectural lesson is broader than Hermes: context-local identity and process-global state must not be treated as the same ownership domain. Any shared cache or environment bridge that controls execution location needs an explicit fence against request/profile overrides.

Repeated environment reloads must be idempotent against the process’s own writes

Hermes PR #114427, merged on 17 September 2026 at 23:00:41 UTC as d04f6f79, fixes a separate P1 environment-lifecycle defect tracked as issue #109902. load_hermes_dotenv() is deliberately not a one-shot startup operation: the gateway reloads it per turn, cron reloads it per fire, and plugin discovery, MCP configuration and hermes send can invoke the same loader again. With override=True, python-dotenv interpolated ${VAR} against the live os.environ; a normal self-reference such as PATH=/opt/data/bin:${PATH} therefore consumed the value Hermes had published on the previous pass and prefixed it again.

The failure was cumulative rather than immediately visible. Repeated loads could grow PATH and similarly self-referential variables until the process environment exceeded ARG_MAX, after which child spawns — including terminal tools, MCP servers and Git — could fail with E2BIG. Direct self-reference, absent-at-boot variables, ${VAR:-default}, indirect chains and alternating project/home load shapes are covered by the upstream regression set.

Hermes now resolves dotenv atoms against process-wide original-value tracking rather than blindly treating its own last publication as fresh external input. A prior value is peeled only while os.environ still exactly matches what Hermes last published; a shell, terminal-config bridge or external secret source that changes the value establishes a new baseline instead of being frozen. Files layered inside the same load pass still see the preceding layer, so user, project and managed dotenv composition keeps its intended precedence. The routed multiplex path remains excluded from the process-global load, and agent/secret_scope.load_env_file remains untouched because that path does not interpolate.

The architectural invariant is broader than dotenv: a long-lived harness that reapplies configuration into process-global state must make repeated loads idempotent with respect to its own prior writes while still honoring genuinely external changes. Otherwise a configuration reload can silently become an execution-availability failure far from the loader itself. PR #114427 is included in stable v2026.9.21 / Agent v0.21.4; it does not change UHP, MCP, ACP or A2A wire semantics.

Cross-VM bind mounts need a database journal policy, not a “local path” assumption

Commit d8dcdfd6, now included in stable v0.21.4, adds a preflight guard before enabling SQLite WAL when the database path sits on Linux virtiofs, fuse.virtiofs or 9p variants — filesystems commonly used for host bind mounts by Docker Desktop, OrbStack and Podman. Hermes resolves the database directory, reads /proc/self/mountinfo, selects the longest matching mount point and caches the result by directory.

For a fresh or rollback-journal database on a recognized cross-VM mount, the normal fallback uses journal_mode=DELETE; callers that explicitly require WAL receive WalUnsupportedError. Hermes deliberately does not live-downgrade a database already in on-disk WAL mode, and non-Linux or unreadable-mountinfo paths preserve the prior behavior. The upstream regression is sabotage-verified: removing the new wiring makes the fresh-database cross-VM test fail.

This is not a Hermes-only observation. OpenClaw PR #120597 independently added the same class of guard after a field report of zero-filled database/WAL pages on a VM-backed bind mount; its evidence includes an end-to-end run against a real fuse.virtiofs mount. SQLite’s own WAL documentation states that WAL requires all processes using a database to be on the same host because the WAL index uses shared memory, and therefore does not work across filesystems that cannot preserve that coordination model.

The reusable invariant is: filesystem pathname locality is not enough. Journal and locking mode must be chosen from the actual coherence domain of the storage substrate. A host bind mount that looks like an ordinary local directory inside a container can still cross a VM boundary beneath SQLite.

Bot Screen: human takeover must be an execution lease, not a UI hint

Hermes PR #108914, merged on 23 September 2026 as c80d12b9b98e36178aa41d496e8dd555399fc286, adds a per-profile Xfce desktop on a headless Linux gateway and streams it into Hermes Desktop over noVNC/RFB. A human can take control of the same screen and browser state the bot uses, perform an interactive step, then hand the screen back so the bot continues with that state.

The security-relevant design is not the remote desktop itself; it is the exclusive control lease around the shared execution surface. Hermes persists lease ownership per profile, makes the viewer identity server-issued rather than client-chosen, and keeps the lease visible across processes. While a human holds the lease, computer-use actions are refused with human_has_control; local browser commands are fenced by the same ownership model; capture results are checked before persistence or auxiliary vision; and an action admitted before takeover is discarded if the lease epoch changes while it is running.

That last point closes an important time-of-check/time-of-use gap. Blocking only new tool calls is insufficient: a human can take over after an agent action has passed admission but before the result returns. A control handoff therefore needs both a pre-dispatch owner check and a post-dispatch generation/epoch fence so stale work cannot become visible or mutate later state after authority moved.

Disconnect semantics are also part of the control boundary. The reviewed implementation does not treat an abnormal viewer drop as an implicit hand-back: unexpected WebSocket/RFB disconnects keep the human exclusion in place, while an orderly close or explicit hand-back can return control to the agent. A corrupt present lease record also fails toward human ownership rather than silently restoring agent control. This prevents a flaky network from resuming automation in the middle of a sensitive interactive step.

State continuity and action authority remain separate. The desktop launcher and the agent browser use the same Chromium identity/profile so authenticated browser state can survive the handoff, but shared state does not grant simultaneous action authority. Read-only thumbnails are suppressed while a human controls the screen, and connection/profile identity is carried into screen events so two hosts with the same profile path do not collapse into one control lane.

The transport itself is scoped as well: the display WebSocket uses a short-lived one-shot ticket minted over the already authenticated gateway connection, and a display ticket is not accepted as general gateway authentication. Install-time sudo prompts are returned to the originating connection/profile rather than whichever gateway happens to be foreground. Those details generalize to a broader rule: a remote-control credential should authorize the narrow display/control channel it was issued for, not become a bearer token for the wider agent gateway.

The upstream PR reports live Xvnc/Xfce verification plus focused lease, display-ticket, installation and Desktop tests, and it records several review rounds where cross-process leases, mid-flight fencing, browser-tool bypasses, abnormal-disconnect behavior, viewer identity, capture leakage and multi-host event scoping were reproduced and corrected. This is implementation evidence, not independent certification by this site.

The original #108914 scope did not make Bot Screen available inside the published hosted image. Hermes follow-up commit 686c34d3f6f3c433bbfed8f45b60f208a18849d1, merged on 24 September 2026, closes that delivery gap with a separate desktop image variant. Existing unsuffixed :latest, :main and :v* tags remain the slim image, while :latest-desktop, :main-desktop and :v*-desktop carry Xvnc/Xfce plus a headed Playwright Chromium. The split is deliberate: hosted instances are unprivileged, have no sudo path for package installation and treat /opt/hermes as sealed, so the image layer is the capability-delivery boundary rather than an on-demand runtime install.

The same follow-up hardens bootstrap state around that variant. XDG_RUNTIME_DIR is moved to container-scoped /tmp/hermes-runtime, seeded mode 0700 and refused when foreign-owned rather than falling back to the shared /opt/data volume. The Bot Screen memory gate now reads cgroup working set — usage minus inactive_file — so reclaimable page cache does not monotonically tighten the restart gate after an idle screen stops. The desktop variant also carries the full Chromium build needed for a visible browser while preserving the intended shared browser identity between agent and human. These are deployment/runtime semantics, not a UHP extension.

The durable lesson is: an interactive control feature is not deployable merely because its API and lease semantics exist. The runtime image must contain the display/browser substrate, bootstrap directories must have trustworthy ownership, and resource admission must measure the resource it actually intends to constrain. Product-level hosted/dashboard integration remains a separate question; this commit establishes image availability, not a general cloud-browser protocol.

GitHub Agentic Workflows: Cloud Hypervisor consolidation is now released

GitHub Agentic Workflows documented a material sandbox-runtime transition on 5 September 2026: the specialized gvisor and docker-sbx runtime options were deprecated and preview cloud-hypervisor became the supported direction when a workflow needs a hardware-virtualized microVM boundary. The ordinary docker runtime remains available with its network-isolation and proxy-enforcement model.

The consolidation commit 19f7c074 is now an ancestor of stable v0.88.7, published 8 September 2026, so this is no longer only current-main evidence. The 5 September documentation says Cloud Hypervisor requires a GitHub-hosted Ubuntu x86_64 runner with /dev/kvm; the compiler performs host checks and provisions digest-pinned runtime assets.

The migration is useful evidence for a broader harness-design principle: sandbox policy and sandbox mechanism are separate layers. A product may keep the same workflow-level execution contract while retiring one isolation substrate, retaining a lower-cost/default container profile, and directing higher-isolation workloads toward a hardware-virtualized runtime. UHP does not standardize that substrate choice, so a UHP-compatible server could make an equivalent migration without changing its external protocol contract.

The same line also exposes why microVM adoption needs explicit filesystem policy rather than only a stronger isolation primitive. Follow-up commit 36ab2fbe grants the repository-memory directory /tmp/gh-aw/repo-memory/<id> write access under the Cloud Hypervisor sandbox after agents otherwise hit a read-only-filesystem failure. That is not a weakening of the protocol boundary; it is evidence that writable state has to be deliberately projected into the sandbox when the runtime’s default filesystem policy becomes stricter.

Pi v0.85.1: remote harness support is explicitly source-only

Pi v0.85.1 turns the earlier current-main distribution boundary into a released product fact. Its coding-agent changelog says SDK import failures in v0.85.0 were caused by unintentionally publishing internal experimental code and dependencies. The fix keeps the experimental client and experimental/plugin subpaths and the server/client commands source-only through pi-test.sh; the supported local SDK and stdio RPC API remain unchanged.

The underlying current-main change, commit 1382777e, excludes those remote-harness paths from published npm packages and standalone binaries, keeps the remote-harness packages as development dependencies, and adds packed-consumer checks. The stable release therefore confirms the key maturity distinction: remote-harness source code exists, but it is not a supported packaged runtime surface in v0.85.1.

Practical invariants for remote agent execution

The current implementation evidence supports a reusable checklist:

Bind every remote environment to an explicit session/profile owner. Do not infer owner identity from a mutable process-global default.
Separate variable-name policy from secret-value transport. Allowlisted names, blocked provider credentials and transport mechanics are distinct controls.
Assume connection reuse has policy state. Multiplexed SSH or pooled transports can cache capability/environment choices that must be keyed or invalidated.
Validate artifact egress independently from command execution. A harness being allowed to read a file does not mean the gateway should deliver that file to a user.
Canonicalize remotely and fail closed. Symlink/realpath resolution must happen in the filesystem that actually owns the path; unresolved targets must not become a bypass.
Bound transfer at the source. Size checks after a remote stream reaches host memory are too late for unbounded or hostile sources.
Keep sensitive runtime stores explicitly non-exportable. Session databases, browser profiles, credentials and sidecars need deny rules even when they are recent or adjacent to normal artifacts.
Publish maturity separately from source presence. Experimental remote-server/client code should not be described as a stable packaged capability until its distribution boundary says so.
Treat sandbox substrate and sandbox policy as different controls. A stronger microVM boundary still needs explicit writable-state, network and credential projections; protocol compatibility alone does not define them.
Choose database concurrency mode from storage coherence, not path shape. Before enabling WAL, identify whether the state store actually has the shared-memory and locking guarantees WAL requires; use an explicit lower-concurrency fallback or fail closed when it does not.
Bind remote authentication metadata to the request path that actually runs. OAuth partitions, redirects and connection registries must resolve the same scoped headers as ordinary gateway traffic, and decrypted values must be sanitized before any request API sees them.
Make repeated process-global configuration loads idempotent against their own previous output. Preserve a true baseline, distinguish external mutation from self-published state and verify that repeated turns/cron/plugin/MCP paths cannot accumulate interpolation or other derived values.
Model human↔agent GUI takeover as an exclusive lease. “View only” presentation flags are not enough; the execution layer must know which actor currently owns control.
Fence in-flight work across control-owner changes. Re-check ownership at dispatch and reject results produced across a lease-generation change so pre-takeover work cannot leak into the human-controlled interval.
Separate state continuity from action authority. Sharing a browser profile can preserve login/session continuity, but it must not imply that the human and agent may drive the same state concurrently.
Treat deployable capability as image/runtime state, not only API state. A hosted control surface is unavailable if the immutable image lacks its display/browser substrate or its bootstrap directories cannot be trusted.

Relationship to UHP, ACP, MCP and A2A

UHP can sit outside these remote-execution choices. A UHP server may run its selected harness locally, inside a container, over SSH, through a remote execution service, behind another internal process boundary, or against a remotely viewed stateful desktop. The current UHP specification does not require one of those deployment models or define a human↔agent GUI control lease.

Likewise, ACP or another agent protocol can be used as an internal child/runtime transport in a composed harness, but that does not standardize SSH environment forwarding, artifact extraction, state-database journal policy or exclusive screen/browser ownership. MCP standardizes model/tool context integration rather than the host↔sandbox execution boundary described here, and A2A standardizes agent-to-agent interaction rather than a terminal backend’s filesystem/credential policy or human takeover semantics.

Passing UHP conformance therefore should not be read as a sandbox-security, storage-durability or interactive-control safety certification. The protocol and the execution substrate answer different questions.

For adjacent context, see UHP security and trust boundaries, harness composition and subagent delegation, profile isolation, UHP and Hermes and UHP and Pi.

Current boundary

As checked on 24 September 2026 for UHP, HarnessRouter and Hermes, with GitHub Agentic Workflows and Pi retaining their explicitly dated evidence below:

UHP current is 2026-09-28 Draft (protocol coordinate checked 4 October 2026).
At the 24 September source cutoff, HarnessRouter stable and checked main were both v0.23.12 / 5c2d3bb3e8b07297f2e82fd3a5075d430fb8f446. The release-train changes after this page’s earlier v0.18.1 coordinate do not change the remote-execution semantics documented here.
Hermes latest stable is v2026.9.24 / Agent v0.21.5. The remote-execution evidence through 2e24e06e, cross-VM WAL guard d8dcdfd6, PR #110987 / 03b0c794, PR #114427 / d04f6f79, Bot Screen PR #108914 / c80d12b9 and hosted-image delivery 686c34d3 are all in that release’s ancestry. Checked Hermes main is later than the stable tag and remains a separate development coordinate.
GitHub Agentic Workflows v0.88.7 is the last stable coordinate verified for this page’s Cloud Hypervisor evidence on 18 September; the consolidation commit is in that release’s ancestry.
Pi v0.85.1 is the last stable coordinate verified for this page’s remote-harness distribution boundary on 18 September; its experimental remote harness is explicitly source-only in that release’s supported distribution boundary.
No native UHP adoption by upstream Hermes, GitHub Agentic Workflows or Pi is established by these changes.
No standardized UHP↔remote-terminal, UHP↔microVM, UHP↔remote-harness, UHP↔Hermes-Desktop-auth, UHP↔dotenv-reload or UHP↔human-screen-handoff binding is inferred, and UHP does not prescribe OAuth browser-session routing, Cloudflare Access headers, process-global environment interpolation, SQLite journal, container-mount, hosted-image packaging or GUI control-lease semantics.

Short answer

Trace a missing artifact through both directions of trust

Why this deserves a separate architecture layer

Hermes: released remote boundaries plus interactive desktop handoff

Remote gateway OAuth: authentication headers must follow the real browser session

SSH environment forwarding: names and values have different transport surfaces

Remote artifacts: egress is a separate validation step

Conversation and credential stores are never ordinary artifacts

Multiplexed profiles must not share terminal identity accidentally

Repeated environment reloads must be idempotent against the process’s own writes

Cross-VM bind mounts need a database journal policy, not a “local path” assumption

Bot Screen: human takeover must be an execution lease, not a UI hint

GitHub Agentic Workflows: Cloud Hypervisor consolidation is now released

Pi v0.85.1: remote harness support is explicitly source-only

Practical invariants for remote agent execution

Relationship to UHP, ACP, MCP and A2A

Current boundary

Primary sources