Best possible solution:

Land this only after the generic harness prewarm hook exists on the target branch and the real TUI submit path passes or otherwise enforces the warmup busy state with focused TUI proof.

Do we have a high-confidence way to reproduce the issue?

Yes for the review finding: source inspection shows the PR's new activityStatus check depends on a field the real runTui caller does not pass. No runtime execution was needed to establish that caller-path mismatch.

Is this the best way to solve the issue?

No. The prewarm direction is plausible, but the current diff does not wire the submit gate through the real caller and depends on a closed unmerged base hook.

Full review comments:

• [P1] Pass activity status through the real submit gate — src/tui/tui.ts:382-384
  The new warming runtime check only looks at params.activityStatus, but the real editor submit path still calls canSubmitTuiChatMessage without that field, and the params type in this file does not declare it. As a result users can still submit during warmup, and a typecheck should reject the new property access. Thread the current activity status through this caller or gate the send path directly.
  Confidence: 0.94

Overall correctness: patch is incorrect
Overall confidence: 0.9

AGENTS.md: found and applied where relevant.

Codex review notes: model gpt-5.5, reasoning high; reviewed against 309fdd95dad5.

Label changes:

• add rating: 🧂 unranked krab: Overall readiness is 🧂 unranked krab; proof is 🌊 off-meta tidepool and patch quality is 🧂 unranked krab.
• add status: ⏳ waiting on author: ClawSweeper has contributor-facing work open and is waiting for author action. Not applicable: This is a maintainer-authored draft PR, so the external contributor real-behavior-proof gate does not apply; the PR body lists focused local verification instead.
• remove rating: 🌊 off-meta tidepool: Current PR rating is rating: 🧂 unranked krab, so this older rating label is no longer current.

Label justifications:

• P2: This is a normal-priority TUI startup/send-path improvement with limited blast radius but real user-visible availability impact.
• merge-risk: 🚨 availability: Merging changes first TUI startup and submit availability around runtime prewarm, and an incorrectly wired or unproven gate can stall or race first send.
• rating: 🧂 unranked krab: Overall readiness is 🧂 unranked krab; proof is 🌊 off-meta tidepool and patch quality is 🧂 unranked krab.
• status: ⏳ waiting on author: ClawSweeper has contributor-facing work open and is waiting for author action. Not applicable: This is a maintainer-authored draft PR, so the external contributor real-behavior-proof gate does not apply; the PR body lists focused local verification instead.

PR surface:

Source +56, Tests +52. Total +108 across 6 files.

What I checked:

• Repository policy read: Root OpenClaw review policy and TUI/runtime guidance were read before review; scoped TUI and agents guides are relevant because this PR changes TUI startup and agent runtime prewarm behavior. (AGENTS.md:1, 309fdd95dad5)
• Scoped TUI guidance read: The TUI guide says fake-backend PTY tests do not prove embedded backend runtime, providers, session persistence, or live streaming, which matters for this startup/runtime change. (src/tui/AGENTS.md:1, 309fdd95dad5)
• PR diff adds warmup submit gate: The PR diff adds a warming runtime check inside canSubmitTuiChatMessage and a test that directly passes activityStatus, making caller wiring part of the behavior being reviewed. (src/tui/tui.ts:382, aaa2bb980b2a)
• Real TUI caller omits activityStatus: Current runTui constructs the canSubmitTuiChatMessage argument without activityStatus; the PR diff does not update this caller, so the new warmup gate is not reached by the real editor submit path. (src/tui/tui.ts:1328, 309fdd95dad5)
• Current helper type has no activityStatus field: Current main's canSubmitTuiChatMessage parameter type does not include activityStatus; the PR's new property access needs the type and caller updated together. (src/tui/tui.ts:370, 309fdd95dad5)
• Current main lacks prewarm symbols: A targeted search on current main finds no prewarmAgentHarnessRuntime, prewarmAgentRuntime, or warming runtime symbols, matching the PR body's statement that this is stacked on the separate harness prewarm hook. (309fdd95dad5)

Likely related people:

• RomneyDa: Current-main blame for the TUI submit helper/session actions points at Dallin Romney, and related open TUI PRs in the provided context modify the same createSessionActions/runTui surface. (role: recent adjacent TUI contributor; confidence: medium; commits: 5a6472718da9, 21f2ff2ccdff; files: src/tui/tui.ts, src/tui/tui-session-actions.ts)
• steipete: Peter Steinberger has recent history on shared session model resolution and broader TUI refactors that the embedded backend prewarm path relies on. (role: adjacent refactor owner; confidence: medium; commits: 32ebaa37574e, 38752338dcbc; files: src/tui/embedded-backend.ts, src/tui/tui-session-actions.ts)
• vignesh07: Vignesh Natarajan authored recent TUI optimistic-message and busy-state related work, which is adjacent to the first-submit blocking behavior changed here. (role: TUI submit/session-state feature contributor; confidence: medium; commits: 61a0b0293104, fca0467082cb; files: src/tui/tui.ts, src/tui/tui-session-actions.ts)

• 🦀 challenger crab: rare, exceptional readiness with strong proof, clean implementation, and convincing validation.
• 🦞 diamond lobster: very strong readiness with only minor maintainer review expected.
• 🐚 platinum hermit: good normal PR, likely mergeable with ordinary maintainer review.
• 🦐 gold shrimp: useful signal, but proof or patch confidence is still limited.
• 🦪 silver shellfish: thin signal; proof, validation, or implementation needs work.
• 🧂 unranked krab: not merge-ready because proof is missing/unusable or there are serious correctness or safety concerns.
• 🌊 off-meta tidepool: rating does not apply to this item.

Shiny media proof means a screenshot, video, or linked artifact directly shows the changed behavior. Runtime, network, CSP, and security claims still need visible diagnostics.

• ClawSweeper keeps one durable marker-backed review comment per issue or PR.
• Re-runs edit this comment so the latest verdict, findings, and automation markers stay together instead of adding duplicate bot comments.
• A fresh review can be triggered by eligible @clawsweeper re-review comments, exact-item GitHub events, scheduled/background review runs, or manual workflow dispatch.
• PR/issue authors and users with repository write access can comment @clawsweeper re-review or @clawsweeper re-run on an open PR or issue to request a fresh review only.
• Maintainers can also comment @clawsweeper review to request a fresh review only.
• Fresh-review commands do not start repair, autofix, rebase, CI repair, or automerge.
• Maintainer-only repair and merge flows require explicit commands such as @clawsweeper autofix, @clawsweeper automerge, @clawsweeper fix ci, or @clawsweeper address review.
• Maintainers can comment @clawsweeper explain to ask for more context, or @clawsweeper stop to stop active automation.

• Eggs appear after the PR passes real-behavior proof. It is here for vibes, not verdicts: it does not change labels, ratings, merge decisions, or automation.
• The shell reacts to review momentum: open follow-up work warms it up, re-review makes it wobble, and a clean final review lets it hatch.
• Hatchability usually comes from sufficient real-behavior proof, no blocking P0/P1/P2 findings, no security attention needed, and clean correctness. A merged PR is already final, so merge makes the egg hatchable independently.
• The hatch is seeded from this repository and PR number, so the same PR keeps the same creature; the reviewed head SHA can only change safe visual details.
• Rarity is just collectible sparkle: 🥚 common, 🌱 uncommon, 💎 rare, ✨ glimmer, and 🌈 legendary.