4.3 KiB
Actual interactive assignment launch — owner finding
This is conditional source preparation. The founder's current choice between the actual interactive Codex assignment and native-worker-first acceptance is pending; this document selects neither and does not treat one as proof of the other.
Existing reusable surfaces
- sand-boxer owns capability.execution.sandbox-provision: provisioning, protected runtime mounts, execution environment, egress and teardown. Its current bwrap runner accepts bounded stdin and uses subprocess.communicate; this is command execution, not an admitted long-lived interactive Codex session transport.
- glas-harness owns capability.execution.profile-harness: profile resolution, assignment attribution, sandbox creation, rein dispatch and cleanup. Its gateway executes one request. The committed concrete rein descriptors are Claude Code unattended and open-weight; no Codex interactive descriptor or admission receipt was found in these source catalogs.
- rein-aharness owns capability.execution.scheduled-agent-rein: Activity Core claim, heartbeat and routing plus repository acceptance. Its f599 offline startup is proven; it does not launch this current interactive Codex assignment.
- state-hub/scripts/configure-codex.sh registers local service/tool settings. It does not isolate the Codex parent process or admit a restricted execution host.
Concrete next owner return, if interactive scope is selected
Lead: glas-harness for the exact assignment launch/admission contract, with sand-boxer delivering the executable boundary and railiance-infra the separate account. The owner of the CURRENT frontend/executor attachment must be identified explicitly: the local catalog does not establish who can reattach this managed interactive session. Do not silently replace it with a new CLI session.
Return one versioned launch packet containing:
- The selected frontend/transport and actual launch point before the first agent tool: pinned executable/profile, UID, workspace, private HOME/state, inherited environment allowlist, allowed tool transports and explicit supervisor identity.
- A way to start the entire interactive executor/session under that boundary, or a documented inability of the current frontend to attach to it. No parent process with host admin authority may remain agent-callable. For a selected CLI frontend, implement/test initial launch inside the owner boundary; for a selected managed frontend, obtain its supported restricted-executor attachment contract. Neither path is delivered by a child sandbox launched from this current session.
- Positive interactive start/input/output and cancellation/teardown proof, followed by reconnect/resume evidence that uses the same restricted identity and reviewed profile. No fallback to the old host executor on refusal or reconnect failure.
- A complete tool-path inventory: shell/files, SSH agents, containers, GitOps write paths, plugins/MCP and remote connectors. Remove or route all privileged external paths to a separately owned exact-approval executor; filesystem isolation alone cannot restrict an external connector's independent authority.
- Native proof from that assignment: original and per-namespace auth denials, old host/admin paths denied, sanitized exact approved action succeeds, and changed/unapproved/expired/replayed actions refuse. Bind all receipts to that assignment and actual runtime revision. Keep autopilot disabled.
No new general supervisor service is required. The first missing deliverable is this owner-supported initial launch/attachment, not another disposable bwrap test. The native-worker-first path may reuse existing f599/Glas/rein work but must retain the interactive migration gap as unfinished unless the founder explicitly changes that scope. Provider login/credential work is outside this source preparation.
Official context, not a claim about this session: OpenAI's self-hosted environment documentation describes an executor started inside the selected isolated environment and keeping application credentials outside it. That reinforces the launch-point requirement but does not prove this frontend uses that API or supports reattachment: https://developers.openai.com/api/docs/guides/agents-api/environments/self-hosted