The agent that asks, plans, and pursues. OpenClaw runs on the Codex runtime, but OpenClaw users don't get the three interactive primitives Codex-native users take for granted: the agent can't ask a structured question, can't enter a reviewable plan mode, and can't be handed a long-running goal it pursues on its own. This issue is the master hub for the series that closes that gap: the architecture, the PR, exactly how to try and test each feature, and the follow-up roadmap.

The full flow — plan mode, the live plan pane, inline approval, and an inline agent question. A 30s narrated walkthrough covers goal mode too.

The gap, precisely (verified against both codebases)

The pattern worth noticing: the primitives were already merged (update_plan, goal state, a codex user-input bridge, stream:plan events, approval UIs, channel buttons) — this series is the completion layer. Every feature rides an existing choke point rather than inventing a parallel system: the question manager mirrors the exec-approval manager; the plan gate lives in the one before-tool-call hook every tool execution funnels through; the goal driver fires through the cron system-event path. That's why the diff stays small for what it delivers.

The mental model: one interaction pipeline, two producers

• Native tools (all models) — ask_user_question, plan-mode lifecycle tools, the goal driver: first-class OpenClaw features that work on Anthropic/Google/any model.
• Codex pass-through (codex-runtime sessions) — the runtime's own request_user_input converges onto the same question pipeline (a structured answer and the legacy free-text path race; the loser is cancelled). Plan/goal wire bridges are documented follow-up seams.
• One rendering surface, Codex-Desktop-shaped — in the Control UI, questions and plan-approval render as inline cards in the chat composer (not page-locking modals), the active plan docks in the right sidebar (always viewable, full checklist), a mode selector by the gear toggles plan/goal (mutually exclusive), and the goal editor is a focused modal. Telegram inline keyboards, Slack Block Kit, and numbered-text + /answer /plan /goal on every other channel. Ask on one surface, answer from another: resolution is global with scope/turn-source visibility, exactly like exec approvals today.

flowchart LR
  subgraph Producers["Two producers, one dialect"]
    N["🤖 Native tools (all models)<br/>ask_user_question · update_plan · plan mode · goal driver"]
    X["⚙️ Codex runtime pass-through<br/>item/tool/requestUserInput · turn/plan/updated"]
  end
  N --> GW["Gateway<br/>global QuestionManager (cross-surface resolve)<br/>plan state · goal state + goal.updated"]
  X --> GW
  GW --> UI["🖥️ Control UI<br/>inline composer cards · right-sidebar plan · mode selector · goal modal · Pursuing-goal pill"]
  GW --> TG["Telegram<br/>inline keyboards"]
  GW --> SL["Slack<br/>Block Kit buttons"]
  GW --> TXT["Every channel<br/>numbered text · /answer · /plan · /goal"]

Why the goal driver is safe to leave running

sequenceDiagram
  participant T as Turn completes
  participant D as Goal driver (debounced)
  participant G as 4 gates
  participant S as System-event turn
  T->>D: arm (debounce + jitter) — the ONLY thing that arms it
  D->>G: on wake: goal active? · no active run? · queue empty? · ceiling not hit?
  G-->>D: any gate fails → re-arm silently (no fire)
  G->>S: all pass → enqueue steering prompt + heartbeat wake
  S->>T: turn runs with NORMAL privileges — exec approvals still block (tested)
  Note over D: after a FIRE the driver never self-re-arms —<br/>only the next turn-completion arms it. No tight loop, by construction.

Layered brakes: debounce+jitter · the four gates · a durable no-progress ceiling (auto-pause, default 3) · budget limits (budget_limited disarms mid-wait) · an experimental flag (default off) · host-only pause/stop (the model can only mark complete|blocked, mirroring Codex).

🔍 Try it (per-feature test map)

The PR

• PR Interactive parity with the Codex runtime: ask-user-question · plan mode · goal mode #102261 — the full series as one take-apart branch (commit groups: question infra → plan mode → goal mode; each group independently revertable/splittable — happy to split into 3 stacked PRs on request).

Follow-ups (filed as the post-merge roadmap; deliberately out of the first PR)

• Codex plan-collaboration bridge — map OpenClaw plan mode onto ModeKind::Plan via thread settings (no plumbing exists in the codex extension today; documented seam).
• Codex goal bridge — thread/goal/set|get|clear + thread/goal/updated ↔ session goal (same: seam documented, zero plumbing today).
• Plan-mode power-ups — archetype prompting, escalating retry, plan-tier model routing (proven in a 156-case-parity-hardened plugin implementation; ported only if maintainers want them in core).
• Question multi-select + secret inputs (isSecret is already in the shared schema).
• Research-subagent allowance in plan mode (currently vetoed for gate hardness; relaxable by policy).

How this stays lean

No new dependencies anywhere in the series. Every human-in-the-loop interaction (questions, exit-plan approval, goal edit) is ONE pipeline — the same global-manager + scope-visibility pattern exec approvals already use. Features cluster in additive dirs; the tool gate is one policy at one choke point; the driver is one scheduler wired to two existing seams.