Repository navigation
fix(console): a provisioning Namespace says so before Create - #2924
Conversation
On a Namespace that is not ready, the status note is a warning status block (still a polite status) on the Agents list, the Create Agent start page and now the Create form too. Create Agent stays enabled on a provisioning Namespace, since drafts are still accepted (#2867), but it points at the note, and the empty state says a draft can be saved now and deployed once the Namespace is ready. On an Installation that provisions Dedicated Agents, the form says one can be created once the Namespace is ready instead of promising it deploys when created (finding 1990).
|
🦞👀 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. |
clawsweeper
Bot
added
clawsweeper:intake:bug
|
Codex review: needs maintainer review before merge. What this changesThis PR makes Namespace readiness warnings visible throughout Agent creation and explains when deployment must wait. Example: A user selects the provisioning default Namespace and chooses Start without Preset.
Review scores
ProductKind: Bug fix · Worth it: Yes · Fix scope: Complete Merge readiness✅ Ready for maintainer review Keep this PR open: it addresses misleading Namespace readiness guidance still present on main, preserves supported draft creation, and introduces no identified code defect. Priority: P2 Before mergeNone. FindingsNone. Tests
Agent review detailsHow this fits togetherThe OCC console renders Namespace status and Installation capabilities into Agent creation guidance; existing API owners continue to authorize and admit writes. flowchart TB
N[Namespace status] --> G[Existing readiness guidance]
G --> L[Agents list]
G --> S[Create start page]
G --> F[Create form]
C[Installation capabilities] --> F
F --> A[Existing authorized API operations]
Technical reviewBest possible solution: Keep Namespace readiness guidance visible throughout Agent creation while preserving supported draft saves and existing API gates. Do we have a high-confidence way to reproduce the issue? Yes: current-main form construction drops the existing warning and its capability text promises immediate Dedicated deployment; the supplied before screenshots corroborate the list guidance problem. Is this the best way to solve the issue? The focused presentation repair fits the existing namespaceCreation owner, preserves intentional draft support, and leaves admission and authorization unchanged. AGENTS.md: found and applied where relevant. Codex review notes: model internal, reasoning medium; reviewed against cf2cc2ec3c77. Provenance checked
TestingProof path: in-process harness. SecurityNone. EvidenceWhat I checked:
Likely related people:
Review metrics
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, 5:52 AM ET / 09:52 UTC. |
Problem
Finding 1990 (D649), seen live on oce-dogfood-b with a real provisioning Namespace:
Change
Respecting #2867's narrowing, drafts stay allowed on a provisioning Namespace, and Create Agent stays enabled there. The page only says what will happen.
.status,data-tone="warning") on the Agents list, the Create Agent start page, the "Creating Agents is not available" panel of a blocked Namespace, and the Create form. It stays a politerole="status", since it is shown on load rather than in answer to an action.aria-describedby; before, only a blocked Namespace had this). On a provisioning Namespace the empty state reads "You can save an Agent draft here now. It can be deployed once this Namespace is ready." instead of the plain invitation.Pages / Create Agent / Form, Namespace still provisioning. The existingPages / Agents / Empty, Namespace still provisioningandPages / Create Agent / Namespace still provisioningshow the new block.Presentation only: no API, authorization or gating change. A blocked Namespace (failed, deleting, or adopting an existing namespace) is gated as before; only its note's look changes.
Verification
tests/browser/console-namespace-not-ready.test.mjs(real API fixture, first-run provisioningdefaultNamespace):list.mjs), with the list-return and agents files (56/56).merge-treeof this head against the open PRs that touch console, Storybook or browser-test files (fix(console): match Chromium's break points for long Agent names #2916, fix(console): let the create preflight carry any configuration both creates accept #2833, feat: add per-agent sandbox network policies and denial review #2599, feat(console): show the authorized native Gateway people roster #2596, feat(console): stop and delete Agents from the Agents list #2524, Draft implementation: managed outbound HTTPS for dedicated Gateways #2518, fix(console): distinguish stale runtime status from loss of access #2505, fix(console): keep followed logs steady and report the first output #2502, Add OCE policy simulation and tester for network and plugin actions #2445, fix: preserve native plugin permissions across Harness selection and admission #2258, fix(console): grant Agent access to accepted Configuration Secrets #2255, Support custom Installation profiles and readable Preset starters #2253, feat(auth): sign people in to occ with a device code (rfc-0019) #1619, feat: assign configured OpenClaw roles to Agent users #906, docs(specs): propose rfc-0019 for repository options without a repository driver #878, feat: add Agent workload tags #115, plus our fix(console): secret picker errors name the field and stay visible #2922 and fix(console): refusals for readers are alerts, in view, and diagnostics needs operate #2923) shows the same conflict count as main for each: zero new conflict hunks. feat(console): stop and delete Agents from the Agents list #2524 rewriteslist.mjs, so the list's note is built inline with the status block's markup and the import line is left unchanged.Media (Storybook, committed in 15b0f88 and removed before squash)
Agents list, provisioning Namespace: before, plain muted text and the plain invitation; after, a warning status block, and the empty state says what will happen
Create Agent start page: the note becomes a warning status block
Create form after Start without Preset: before, no note; after, the note stays
Story: new
Pages / Create Agent / Form, Namespace still provisioning; existingPages / Agents / Empty, Namespace still provisioningandPages / Create Agent / Namespace still provisioning. Before shots are the same stories on main'slist.mjsandcreate.mjs.Recording: walkthrough (1280x800, webm): the provisioning Namespace's warning note on the Agents list, the start page and the Create form, with the wait named in the capability line. Committed in 1dddc81 and removed before squash.
Risks
Low. The copy changes on a not-ready Namespace only; ready Namespaces render as before. Finding 1990; UX plan A5 and C1.