Fix Codex exec approval handling

[fancyboi999]

Background

Users reported two related issues where Codex exec approvals either failed validation or left the session stuck after selecting “Stop and explain.” This produced invalid MCP elicitation responses and prevented follow-up messages from being processed. (Refs: #503, #522)

Solution

• Preserve codex_* fields from the elicitation payload so we can reliably detect Codex exec approvals.
• Return an MCP-compliant result (action) while also including legacy fields (decision, optional content) required by older Codex runtimes.
• Track exec approval requests and propagate the “abort” decision to the run loop, so a “Stop and explain” cleanly ends the current turn and new user messages are handled normally.

Compatibility

This keeps compatibility with older Codex clients by continuing to send decision/content while remaining valid for the MCP schema. Non-Codex elicitation behavior is unchanged.

Testing

• yarn --cwd packages/happy-cli typecheck
• Manual: verified all three permission paths (accept, decline, stop/abort) in CLI + mobile, and follow-up messages are processed after stop.

[chatgpt-codex-connector]

💡 Codex Review

Here are some automated review suggestions for this pull request.

Reviewed commit: 26de9b1729

ℹ️ 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".

[chatgpt-codex-connector]

Avoid consuming exec approvals for unrelated elicitations

The new fallback path shifts pendingExecApprovals for any elicitation without Codex fields. That means an unrelated MCP elicitation (e.g., another tool asking for user input) will pop and reuse the next exec-approval entry, so the permission handler sees the wrong command/callId and the real exec approval later falls back to a random id with missing command details. This can lead to approvals/denials being applied to the wrong exec command whenever a non-Codex elicitation arrives while an exec approval is pending.

Useful? React with 👍 / 👎.

[fancyboi999]

Addressed review feedback: we now only consume pending exec approvals when the elicitation looks like an exec-approval prompt (Codex message patterns / empty schema). Otherwise we leave the queue intact to avoid mismatched approvals. Commit: ea57ac3.

[HQ-Zhang-233]

very important pull, and hope merged ASAP(Codex user need this)