Repository navigation
feat/openshell first agent codex - #1400
Conversation
|
🦞👀 Pull request received. I will update this pull request when review starts. ClawSweeper review completeClawSweeper finished reviewing this revision. The review result is being finalized. |
|
Codex review: needs real behavior proof before merge. Reviewed October 5, 2026, 5:42 PM ET / 21:42 UTC (Revision 5). ClawSweeper reviewWhat this changesAdds dedicated Codex execution through OpenShell to the first-Agent workflow, with provider-managed runtime files, credential delivery, private routing, two development profiles, and protected integration coverage. Merge readiness⛔ Blocked before merge - 6 items remain Keep open: this adds a distinct supported development path that current main still rejects. Earlier mechanical findings are addressed, but the authority-boundary and existing-state proof requested in the previous review remains outstanding. Priority: P2 Review scores
Verification
How this fits togetherOpenClaw Control Plane authorizes Agent deployments and asks Kubernetes Compute to provision their runtimes. With OpenShell selected, Compute delegates the Codex workload to OpenShell and routes the Agent Gateway through its exposed endpoint. flowchart LR
A[First-Agent command] --> B[Control Plane authorization]
B --> C[Kubernetes Compute]
C --> D[OpenShell Sandbox]
E[Credential Gateway] --> D
C --> F[Agent Gateway]
F --> D
D --> G[Codex model execution]
Before merge
Findings
Agent review detailsSecurityNeeds attention: No new concrete exploit was established, but final-effect credential isolation and withdrawal proof remains required. Review metrics
Merge-risk optionsMaintainer options:
Technical reviewBest possible solution: Deliver the bounded development integration with demonstrated credential isolation, provider lifecycle recovery, and explicit safe refusal of old helper state. Do we have a high-confidence way to reproduce the issue? Not applicable to a feature proposal: current-main documentation explicitly identifies the unsupported OpenShell deployment boundary, while the PR reports successful Compose/k3d model turns. Is this the best way to solve the issue? Yes, the change extends the existing Compute, Sandbox, and Credential Gateway owners and preserves the regular Agent caller; its runtime and existing-state qualification is not yet complete. AGENTS.md: found and applied where relevant. Codex review notes: model internal, reasoning medium; reviewed against a4b3c99fe83f. LabelsLabel changes: No label changes. Label justifications:
EvidenceSecurity concerns:
What I checked:
Likely related people:
Rank-up movesOptional improvements that raise the rating; they are not merge blockers.
Rating scale
Overall follows the weaker of proof and patch quality. Workflow
HistoryReview history (4 earlier review cycles)
|
|
Free's clanker here (an AI agent reviewing on Free's behalf). Review-only pass over #1400 at head VerdictNot ready to land. Three CI-red regressions are mechanical, but there is one security-boundary issue in the new Kubernetes-only dev profile and one lifecycle dead end in the runtime-provider path that need design-level fixes. The CI workflow change: safe
Blocking
Should-fix
Optional
CoverageRead in full: both |
|
Free's clanker here. A dogfood walk of
Embedded OpenClaw accepts an API key for either model provider the console offers (
No push to your branch; take it or leave it. (Dogfood finding D447.) |
The OpenShell first-Agent workflow had no CI caller: local-first-agent-real
supported --harness codex with the OpenShell Sandbox Driver, but only the
k3d-model lane ran it, with the embedded defaults. Its OpenShell branch had
never passed.
- Run it from the openshell lane through a thin wrapper, since the lane audit
forbids mapping one file to two lanes.
- Provision the Compose control plane for OpenShell. The Kubernetes-only
profile installs no Agent Gateway routing, so Compute rejects the dedicated
Codex revision ("Dedicated Harness storage requires gateway routing and node
enrollment").
- Keep the helper's k3d cluster name within k3d's 32-character limit.
- Select the Gateway Deployment by Agent and filter on its Pod template role;
the Deployment itself carries no workload-role label.
- Find the model Secret by its labels in any namespace, because a dedicated
Gateway's Secret lives in the Agent's Gateway namespace.
Verified locally: the self-provisioned Compose plus k3d run passed 3/3 with
real gpt-6-astra turns and cleaned up its stack.
Since openclaw#704 the launcher runs PostgreSQL as StatefulSet postgres, so its Pod is postgres-0 and `kubectl exec pod/postgres` fails at once with "kubectl did not complete successfully (exit 1)". Exec through statefulset/postgres (container postgres) so kubectl resolves the Pod from the StatefulSet selector instead of a hardcoded Pod name. Add a startup test that drives the k3d layout with a fake controller and fake kubectl and asserts the exec target. (cherry picked from commit 147d9fb)
Inside an OpenShell Sandbox, signalling an exited workspace node's process group fails with EPERM, as Darwin reports for a group left with only zombies. killGroup rethrew it from the child exit handler, so the Harness supervisor crashed on the node's first exit, tini exited with it, and nothing relaunched the node while the Sandbox still reported Ready. The revision then stayed REVISION_INCOMPLETE. Signal the child directly on EPERM. A failed retirement no longer ends the node retries that carry enrollment across the Gateway rollout.
The Kubernetes-only profile installed Envoy routing and the browser endpoint
only without a Sandbox Driver, so Compute rejected a dedicated Codex revision
with OpenShell ("Dedicated Harness storage requires gateway routing and node
enrollment").
- Install the routing controllers and browser endpoint for OpenShell too,
keeping Agent native admin disabled as the Compose profile does.
- Give the OpenShell route a fully qualified .svc.cluster.local hostname,
because OpenShell policy DNS does not apply cluster search domains.
- Admit dedicated Agent Gateways to the OpenShell Gateway, which relays their
traffic to OpenShell-exposed Harnesses.
The three dev-up fixture cases that ran this profile end to end now reach the
pinned routing downloads and network-policy probes, which only a real cluster
can prove. Their assertions move to Go tests of the producing launcher steps;
the cluster arguments and OpenShell policies become pure builders for that.
The Kubernetes-only profile trusts its whole Pod CIDR as Gateway proxies, because Envoy Pod addresses change across k3d restarts. The OpenShell supervisor that proxies the workspace node sits in that CIDR without forwarded-client headers, so the Gateway rejected the node with 403 proxy_attribution_required. When the private route's hostname is an in-cluster Service name, send the node through that WSS route, where Envoy attributes the client. Keep the cluster-local Gateway Service URL when the route resolves only outside the cluster, as in the Compose profile. For a wss setup URL, the enrollment rule binds the node executable to the route's host and port with TLS skip, so the node's pinned Gateway CA stays end to end and the route enforces the path.
…ofile Add an explicit control-plane selection to the local first-Agent stack and run the shared proof from the OpenShell lane twice: once with Compose and once with the API, worker, and PostgreSQL in k3d. Each wrapper sets its Harness, Sandbox, and control-plane selection before loading the shared test. Update the OpenShell provisioning flow and testing pages for the in-cluster enrollment route, the Gateway ingress peer, and supervisor retries.
The guide still said stock OpenShell rejects the app-server token projection, so a dedicated Codex deploy on the local profile failed closed. The verifier- only transport and the profile's private routing now let the deployment provision a Sandbox. Point to the first-Agent command for a verified model turn.
…t state Rewrite RFC-0019 to lead with how a first dedicated Codex deploy runs on main 07590c6 today (numbered flow, budgets, failure handling), with the old five-start flow moved to a "why" section and PR history to a short delivery section at the end. Corrections against main: - Pod patch: the tenant worker ClusterRoles are granted per tenant namespace by operator RoleBindings, not cluster-wide; open question 4 restated and linked to the production grant procedure. - Scope: OAuth Codex Agents run a bounded bootstrap Job before the flow (#1994), adding a Job Pod and at least one pending pass. - Open question 1 cites the separate redeploy-handover proposal #1045 and notes Gateway-breaking configuration is now refused before the stop. - Measurements: only the start count is checked in (ratchet); the timing rows are labelled attributed dogfood reports and not rerun since #1400/#1994. - Peer respawn also triggers on a Pod UID or plugin set change; status sources covering every address are refused; dev launcher memory matches the renderer; delivery window ends 2026-10-04.
…roduction without a sandbox (#3318) Production Kubernetes installations without a Sandbox Driver now refuse to start unless drivers.compute.configuration.servicePrincipalCredentials.mode is projectedServiceAccountToken. The guard was lost in #1400. The Helm chart always renders that mode, but a hand-written config could run Agents without their ServicePrincipal credentials. Sandbox-backed installs may still disable it and use the driver's own identity. Startup tests and the production settings reference cover the rule.
Problem
The local first-Agent workflow could not complete a dedicated Codex model turn when Kubernetes Compute selected OpenShell as its Sandbox Driver. The existing path assumed Kubernetes-mounted runtime files, direct Service routing, and raw app-server token delivery that OpenShell must not receive.
The OpenShell integration also lacked protected CI coverage for both supported development profiles: a Docker Compose control plane with k3d compute and a Kubernetes-only k3d deployment.
Change
--harness codexto the first-Agent workflow while preserving embedded OpenClaw as the default.v0.1.3-pre.2and use its experimental provider-managed files and scoped bearer passthrough.Verification
Manual real-runtime proof:
Model response verified:.Repository checks:
pnpm test:files --test-reporter=spec -- tests/integration/full-integration-preflight.test.mjs tests/integration/ci-openshell.test.mjs tests/integration/ci-prepare.test.mjs— 67 passed.node scripts/ci/run-tests.mjs audit— passed with both OpenShell first-Agent tests assigned to the protected lane.pnpm lint— passed.pnpm format:check— passed.pnpm check:workspace— passed.pnpm docs:check— passed.actionlint .github/workflows/full-integration.yml— passed.git diff --check— passed.The initial focused test invocation inside a restricted development sandbox could not create loopback listeners or child processes. The identical command passed when run with those required host capabilities.
Remaining proof:
integration-openshelland an independent reviewer approves the environment deployment.Risks
v0.1.3-pre.2; it is not production qualification.