Repository navigation
feat: add Gateway managed mode to Agent deployments - #2982
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. What this changesThis PR adds default-on Gateway managed mode to Agent deployments, with Installation administrator controls and persisted revision snapshots. Example: An administrator deploys an Agent with gatewayManagedMode set to true.
Review scores
ProductKind: Feature · Worth it: Yes · Fix scope: Complete Merge readiness⛔ Blocked before merge - 5 items remain Keep this maintainer-authored PR open: it addresses a documented administration gap, but a revocation defect and the recorded runtime prerequisite block merging. Priority: P2 Before merge
Findings
Tests
Agent review detailsHow this fits togetherOCC authorizes Agent settings, persists deployment snapshots, and dispatches durable work to Compute Drivers, which launch the Gateway with the selected restrictions. flowchart TB
Admin[Installation administrator] --> API[OCC API]
API --> IAM[IAM Driver]
API --> DB[PostgreSQL snapshots and work]
DB --> Worker[Controller worker]
Worker --> IAM
Worker --> Compute[Compute Driver]
Compute -. runtime prerequisite .-> Gateway[Gateway restrictions]
Technical reviewBest possible solution: Recheck mode-change authority immediately before activation through the existing worker owner, then land with a runtime that enforces all three controls. Do we have a high-confidence way to reproduce the issue? Current-main source and native-admin documentation establish writable configuration drift; head-source tracing establishes the revocation path without executing target code. Is this the best way to solve the issue? Persisting desired and admitted values and composing existing runtime controls fits the platform, but per-pass authorization must also protect activation after awaited preparation. Full review comments:
Overall correctness: patch is incorrect AGENTS.md: found and applied where relevant. Codex review notes: model internal, reasoning medium; reviewed against 69097a7e5ca0. Merge-risk optionsMaintainer options:
Provenance checked
TestingProof path: in-process harness. SecurityNeeds attention: A revoked deployment actor can still complete a mode-changing activation after preparation. EvidenceSecurity concerns:
What I checked:
Likely related people:
LabelsLabel changes:
Label justifications:
Rating scale6/6 🦀 challenger crab · 5/6 🦞 diamond lobster · 4/6 🐚 platinum hermit · 3/6 🦐 gold shrimp · 2/6 🦪 silver shellfish · 1/6 🧂 unranked krab. Overall follows the weaker of proof and patch quality; ✨ marks media proof (a screenshot, video, or linked artifact) that directly shows the changed behavior. WorkflowClawSweeper edits this one comment on every review. Comment Reviewed October 19, 2026, 8:56 PM ET / October 20, 2026, 00:56 UTC. |
|
Codex follow-up on the review of The authorization asymmetry is intentional. A caller with Agent creation permission can accept the restrictive default. An opt-out at creation, or a later change in either direction, also requires Installation administration. A deployer applies the saved setting. A driver without support refuses a managed revision at deployment. Existing revisions retain their original requested-state record. Authorization test The PR description now records the native on/off/on RPC results on writable storage, the disconnected-node limit and the outstanding embedded restart gate. Maintainer validation is still requested. Current CI |
|
Free's clanker here (an AI agent working on Free's behalf). A post-merge review of this PR on main (95b3f6e) found no blocker, but two upgrade questions need a decision from you:
Follow-ups in progress on our side: tests for the two managed-mode permission checks that have no coverage today, refusing at save a Gateway tool policy the pinned OpenClaw would reject on every turn, and refusing at save a new Agent whose Compute can't run managed mode. A separate fix for the Docker Gateway state lock after a stop, which the OpenClaw pin bump exposed, is in #3803. @freeqaz-openai flagging this one for your review. |
…oval (#3803) Docker Compute stops a container (SIGTERM, 10 s) before force-removing it, so a Gateway the running Driver did not observe releases its OpenClaw state lock and its replacement can start. A failed stop still force-removes the container and reports the failure. Finding 2674 (OpenClaw pin from #2982).
|
Free's clanker here (an AI agent working on Free's behalf). An upgrade test of current main on a dogfood cluster found that the OpenClaw pin move in this PR breaks existing dedicated Codex Agents after an upgrade. The Gateway wrapper migrates its own database ( We're working on a fix PR: run the same guarded migration, with backup custody, for the Harness workspace-node state, plus a state-migration test for a dedicated workspace node. Until it lands, upgrading an Installation that has dedicated Codex Agents past this pin will take them down. @freeqaz-openai flagging this one for your review. |
Gateway managed mode defaults on for each Agent. An Installation administrator can turn it off in the version draft to try local changes. An authorized deployer applies the saved setting on the next deployment. Watch the Console walkthrough (14 seconds, simulated Storybook)
The recording at
ef23687691shows the draft saved Off while the active version still records requested On. It uses fictional data and simulated API responses. Capture detailsBehavior
After setup, OCE starts the Gateway with three OC controls that reject native configuration writes, Gateway-local terminals and Gateway-hosted command jobs. The watcher and authorized node-relayed terminals remain available. OCE manages Harness Gateway policy separately in both modes. A revision records the requested setting. Drivers must declare support, and deployment on an unsupported driver is refused. Direct filesystem protection remains follow-up hardening. RFC21 · OC controls
The runtime pins unreleased OC source
9cc4450e, preserves the protected Codex startup setting and ports main’s native browser reconnect behavior to OC’s Solid UI. All five runtime patches applied to the pin and 69 OC reconnect tests passed locally. Codex startup · Browser reconnectVerification
16cfbdddfe, the Kubernetes launcher started packagedOpenClaw 2026.10.6 (9cc4450)from OCE image523e66ecthree times on the same writable volume. With managed mode on, OC refused a config write, a local terminal and a Gateway-hosted command job. With it off, the write persisted, the terminal opened and OC admitted a disabled job. Turning it back on refused a forced run of that saved job. The node-targeted request reached disconnected-node validation. This check used no connected node or controller redeployment.4dc5543f71, all required checks passed. First Agent Smoke verified that both embedded and Codex Agents stopped cleanly and answered chats after an orderly restart. CI Required · First Agent Smoke4dc5543f71. The builds used the checked-in Node base and ran the bridge tests in main’s parallel build stage. Native AMD64 and ARM64 imagesTemporary embedded recovery limitation
After a hard kill, a new embedded Agent can stay down until an operator verifies that the exact previous container stopped, inspects the retained locks, and confirms their fingerprint. This applies with managed mode on or off. The image test kills a Gateway after a successful chat, performs that operator procedure, and requires the replacement to finish its database inspection and answer its first chat with HTTP 200 and
READYon the same volume. The hosted restart case passed in 70 seconds at the original 2 GiB limit. Operator procedure · Passing restart job#2633 owns unattended recovery for a verified Docker predecessor and the first same-Pod Kubernetes restart. #3773 separately proposes preventing competing volume writes during handoff. Neither is a merge prerequisite for managed mode. Unattended recovery #2633 · Storage proposal #3773