feat(codex): surface native questions and goals#109724
Conversation
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: ec4925d89c
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
| onGoalCommand: (command) => void state.handleSendChat(command), | ||
| onQuestionSubmit: (actionToken, answers, onRejected) => | ||
| void state.handleSendChat( | ||
| `/codex answer ${actionToken} answers:${encodeURIComponent(JSON.stringify(answers))}`, |
There was a problem hiding this comment.
Send question answers outside the busy-run queue
When a Codex question is pending, the originating run is still active/abortable, so routing the card submit through handleSendChat("/codex answer ...") goes down the normal message path: /codex is not an executeLocal command, and chat-send.ts queues normal messages while isChatBusy()/hasAbortableSessionRun() is true. That means the structured answer is queued/steered and can be consumed as literal text by the existing pending-input path instead of immediately invoking resolveCodexUserInputAction, leaving option-only questions unanswered or the card stuck; send this via an immediate command/RPC path that bypasses the active-run queue.
Useful? React with 👍 / 👎.
|
Codex review: needs real behavior proof before merge. Reviewed July 17, 2026, 3:19 AM ET / 07:19 UTC. Summary PR surface: Source +719, Tests +665, Docs +8. Total +1392 across 32 files. Reproducibility: yes. the blockers are source-reproducible: submit the question card while the Codex request is still active, and start a thread with an explicit goals opt-in while checking the model-visible goal tool list. Review metrics: 3 noteworthy metrics.
Stored data model Root-cause cluster Members:
Proposal only: this assessment does not dispatch repair, suppress jobs, mutate sibling items, close, or merge anything. Merge readiness Overall follows the weaker of proof and patch quality, so missing proof can cap an otherwise strong patch. Rank-up moves:
Proof guidance:
Risk before merge
Maintainer options:
Next step before merge
Maintainer decision needed
Security Review findings
Review detailsBest possible solution: Route structured answers through an immediate request-scoped gateway command or RPC, preserve explicit goal settings and OpenClaw goal tools unless native replacements are actually enabled, then prove active-run submission and upgrade behavior in a real setup. Do we have a high-confidence way to reproduce the issue? Yes, the blockers are source-reproducible: submit the question card while the Codex request is still active, and start a thread with an explicit goals opt-in while checking the model-visible goal tool list. Is this the best way to solve the issue? No. Reusing the normal chat-send queue is the wrong boundary for a request-scoped response, and native goal replacement should be conditional rather than removing existing tools and settings unconditionally. Full review comments:
Overall correctness: patch is incorrect AGENTS.md: found and applied where relevant. Codex review notes: model internal, reasoning high; reviewed against b64242a4a99a. Label changesLabel changes:
Label justifications:
Evidence reviewedPR surface: Source +719, Tests +665, Docs +8. Total +1392 across 32 files. View PR surface stats
What I checked:
Likely related people:
What the crustacean ranks mean
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. How this review workflow works
Review history (1 earlier review cycle)
|
ec4925d to
041de1a
Compare
Co-authored-by: EVA <[email protected]>
041de1a to
9d6c750
Compare
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: 9d6c7508d5
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
| for (const name of CODEX_NATIVE_GOAL_TOOL_EXCLUDES) { | ||
| excludes.add(name); | ||
| } |
There was a problem hiding this comment.
Keep OpenClaw goal tools while native goals are disabled
When Codex turns use this PR's thread config, features.goals is forced to false in extensions/codex/src/app-server/thread-requests.ts, and upstream Codex only advertises native goal tools when GoalRuntimeHandle.tools_visible() is true (checked openai/codex@3151954 codex-rs/ext/goal/src/runtime.rs and ext/goal/src/extension.rs). This unconditional exclude removes OpenClaw's existing get_goal/create_goal/update_goal dynamic tools before native Codex can replace them, so Codex runs lose all model-visible goal tools even though they were previously provided by src/agents/openclaw-tools.ts; keep these exclusions conditional on native goal tools actually being enabled/visible.
Useful? React with 👍 / 👎.
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: a335277e17
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
| }; | ||
|
|
||
| const CODEX_GOAL_CONTINUATION_DISABLED_THREAD_CONFIG: JsonObject = { | ||
| "features.goals": false, |
There was a problem hiding this comment.
Keep goal feature enabled for
/codex goal
For OpenClaw-started/resumed Codex threads this forces the upstream goal feature off, but this commit also exposes /codex goal and routes it to thread/goal/get|set|clear; Codex gates those native goal RPCs on the same feature flag and returns goals feature is disabled when it is false, so status/set/clear fail on the bound threads where the command is now advertised. Fresh evidence beyond the existing tool-exclusion finding is that extensions/codex/src/command-handlers.ts:452 now routes /codex goal to those native RPCs, so keep the feature enabled for threads with native goal controls or hide/disable those controls while the flag is forced off.
Useful? React with 👍 / 👎.
|
Merged via squash.
|
* feat(codex): bridge native questions and goals Co-authored-by: EVA <[email protected]> * fix(ui): preserve native question text encoding * fix(codex): keep secret answers off action paths * fix(codex): validate native action keys exactly * fix(codex): isolate new goals and free-form answers * style(codex): satisfy extension lint * fix(codex): keep goal replacement non-destructive * fix(codex): separate native goals from continuation * fix(codex): preserve exact native answer labels * test(codex): assert goal continuation stays disabled * fix(codex): remove unused bridge exports * test(codex): refresh goal feature snapshots --------- Co-authored-by: EVA <[email protected]>



Related: #102261
Related: #102260
What Problem This Solves
Codex app-server runs could request structured user input or expose a native thread goal, but OpenClaw only surfaced a flattened text prompt and had no native goal command path. Control UI users could not answer the structured request in place, and operators could not read or update the upstream goal without a second state system.
Why This Change Was Made
This is the first, bounded slice of the approved Codex-parity split. It carries native
request_user_inputquestions through the existing typed presentation seam into channels and the Control UI, then routes request-scoped answers back to the waiting app-server request. Secret questions stay on the warned text path and never receive an action token.It also maps
/codex goalread/write commands directly to upstreamthread/goal/get,thread/goal/set, andthread/goal/clear. There is no parallel goal store. Per-threadfeatures.goalsremains disabled because upstream couples the feature to automatic idle continuation; the app-server RPC gate remains available from its stable process default.The existing
turn/plan/updatedprojector and Activity/UI display already landed onmain, so this PR does not duplicate that implementation.Upstream contract checked directly at
openai/codex@315195492c80fdade38e917c18f9584efd599304:request_user_inputmethod and response path, question/answer wire shapes, and response submissionturn/plan/updatedshape and event projectionThanks @100yenadmin for the original UI/protocol work in #102261. Contributor credit is preserved in the commit history and squash metadata.
User Impact
Control UI users see native Codex questions as structured option/free-form cards and can submit an answer without leaving chat. Supported channels receive typed choice actions. Codex operators can inspect, set, pause, resume, block, complete, or clear the native upstream thread goal through
/codex goal.Automatic goal-driven follow-on turns are deliberately out of scope. Provider-neutral question RPC and autonomous continuation design remain later slices.
Evidence
tbx_01kxqax7egbxg325a8vvqv3jqy, exit 0 after 21m04s. Typecheck, lint, format, API baseline, plugin boundaries, i18n, DB/state guards, and import-cycle checks passed.0.84.