Tracking issue: fullsend-ai/fullsend#879
What should happen
Build a working proof-of-concept of a host-side API server that runs outside an
OpenShell sandbox and is callable by the agent inside. This experiment should
validate assumptions and inform the ADR design (fullsend-ai/fullsend#880).
What to explore
-
Basic API server lifecycle — a minimal HTTP server started by the runner
on the host side, callable from inside the sandbox via curl through the
L7 proxy. Verify the network path works (agent → 10.200.0.1:port → server).
-
Credential isolation — the server holds a credential (e.g. a GitHub
token) and performs operations on behalf of the agent. Verify the credential
never enters the sandbox.
-
Container build delegation — the API server exposes a build endpoint
that triggers podman build or docker build on the host. This tests a
confirmed sandbox limitation: OpenShell's seccomp blocks CLONE_NEWUSER,
AF_NETLINK, and setns, and the agent has zero Linux capabilities, so
neither Docker nor rootless podman/buildah can run inside the sandbox
(NVIDIA/OpenShell#113).
Also verify whether rootless podman/buildah works inside the sandbox
directly — if it does, document what changed.
-
API discoverability — try at least two approaches for making the API
known to the agent (e.g. OpenAPI spec in sandbox, instructions in agent
definition) and document what works best.
-
Per-run auth — implement a bearer token generated per run, passed to both
the server and the sandbox, and validated on each request.
-
Long-running operations — test an operation that takes longer than the
MCP client timeout (~30-60s) to confirm the REST API approach handles it
where MCP would fail.
-
Policy tuning — write the most restrictive L7 network policy that still
allows the agent to use the API server. Document what rules were needed.
Context
Tracking issue: fullsend-ai/fullsend#879
What should happen
Build a working proof-of-concept of a host-side API server that runs outside an
OpenShell sandbox and is callable by the agent inside. This experiment should
validate assumptions and inform the ADR design (fullsend-ai/fullsend#880).
What to explore
Basic API server lifecycle — a minimal HTTP server started by the runner
on the host side, callable from inside the sandbox via curl through the
L7 proxy. Verify the network path works (agent → 10.200.0.1:port → server).
Credential isolation — the server holds a credential (e.g. a GitHub
token) and performs operations on behalf of the agent. Verify the credential
never enters the sandbox.
Container build delegation — the API server exposes a build endpoint
that triggers
podman buildordocker buildon the host. This tests aconfirmed sandbox limitation: OpenShell's seccomp blocks
CLONE_NEWUSER,AF_NETLINK, andsetns, and the agent has zero Linux capabilities, soneither Docker nor rootless podman/buildah can run inside the sandbox
(NVIDIA/OpenShell#113).
Also verify whether rootless podman/buildah works inside the sandbox
directly — if it does, document what changed.
API discoverability — try at least two approaches for making the API
known to the agent (e.g. OpenAPI spec in sandbox, instructions in agent
definition) and document what works best.
Per-run auth — implement a bearer token generated per run, passed to both
the server and the sandbox, and validated on each request.
Long-running operations — test an operation that takes longer than the
MCP client timeout (~30-60s) to confirm the REST API approach handles it
where MCP would fail.
Policy tuning — write the most restrictive L7 network policy that still
allows the agent to use the API server. Document what rules were needed.
Context
runner-hello-world/,openshell-sandbox-evaluation.md.harness schema.