Sandbox host context and local services — investigation

This records an operational gap observed while using Codex: a command may be safe and correct on the host but fail from the managed sandbox because it is in a different network namespace. The aim is to make the correct execution context explicit and repeatable without weakening sandbox isolation.

Observed behaviour

The private-notes stunnel was healthy on the host at 127.0.0.1:8121, but a sandboxed curl could not see that loopback listener. The same read worked in the host context.
WebDAV name resolution likewise failed from the restricted sandbox and succeeded from the approved host context.
Interactive aliases are loaded through ~/.bashrc and ~/.bashrcs. The agent command shell is non-interactive, so alias discovery can falsely suggest that the supported local client is absent.
Using SSH directly to a remote service as a workaround bypasses the intended local tunnel/client route and risks confusing local, personal and infrastructure hosts.

Current safe operating rule

Keep the sandbox as the default. For a known host-local service, use its approved local client or localhost endpoint in the host execution context only; do not substitute direct remote SSH simply because the sandbox cannot reach a loopback socket.

Proposed improvements to investigate

Idea	Benefit	Open question
Local-service registry	One short record per service: localhost address/socket, purpose, supported client, health probe, data classification and whether host context is required.	Where it should live and how agents discover it without loading a large shell profile.
Explicit host-local execution class	A narrow, auditable path for approved localhost clients such as notes and WebDAV, distinct from broad unsandboxed networking.	Whether the execution system can enforce a localhost-only or named-command allowlist.
Non-interactive client wrapper	Install a real notes command on PATH rather than relying on aliases in interactive shell startup files.	Choose command name, configuration source and how it selects public/private stores.
Preflight helper	Before a tool call, report sandbox visibility, host listener state and the correct command/context.	How to expose host socket state safely without giving arbitrary host process visibility.
Unix-domain socket option	For a single trusted local API, a specifically mounted Unix socket may be simpler than TCP and network-namespace exceptions.	Authentication, mount permissions and whether it is preferable to the existing stunnel route.
Target inventory guard	Make local, personal and infrastructure host classes explicit so an agent cannot use a similarly named but irrelevant host as a shortcut.	Best authoritative source and how destructive/remote tools consume it.

Small validation plan

Record the existing private-notes and WebDAV paths in the registry, with a harmless read-only health check for each.
Prototype a non-interactive notes wrapper using the existing local stunnel; confirm reads and writes work without SSH to the service host.
Add a preflight that demonstrates the expected distinction: sandbox cannot see the host-only listener; host context can.
Decide whether a narrowly scoped host-local execution class or a mounted Unix socket gives the clearer security boundary.
Document the chosen route in the agent operating guidance, including the rule against direct-SSH bypasses.

Relationship to existing design

This is an operational complement to the broader sandbox design. It does not propose giving the sandbox unrestricted network access. The broader design already considers a Unix-domain socket for a fixed local service and a tightly controlled network path for other destinations.

Non-goals

No change to the current sandbox security policy as part of this note.
No replacement of the private-notes stunnel today.
No direct remote execution route for routine notes operations.