Conversation
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
ℹ️ 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".
| let event_command = command_tokens_for_event(request.input_chunks); | ||
| if !event_command.is_empty() { | ||
| emit_exec_command_begin( | ||
| context.session, | ||
| context.sub_id, | ||
| context.call_id, | ||
| &event_command, | ||
| context.turn.cwd.as_path(), | ||
| ) | ||
| .await; |
There was a problem hiding this comment.
Emit matching ExecCommandEnd for unified_exec
The new begin event is fired for every unified exec request, but no matching ExecCommandEnd is emitted anywhere in this code path. Clients such as the TUI keep a running command map and clear it only when an end event arrives (handle_exec_begin_now inserts into running_commands, while handle_exec_end_now removes it), so unified exec commands will now remain stuck in a “running” state forever if the request succeeds or fails after this point. Consider emitting an end event (including errors) after the command completes or when acquisition fails to avoid UI spinners that never clear.
Useful? React with 👍 / 👎.
There was a problem hiding this comment.
This is an open question: do we want to handle the end event emission? This seems not relevant by definition of the unified exec tool
# Conflicts: # codex-rs/core/src/tools/events.rs
| .await?; | ||
|
|
||
| let mut begin_events = Vec::new(); | ||
| loop { |
There was a problem hiding this comment.
nit: why loop? two separate wait_for_event_with_timeout should do it
There was a problem hiding this comment.
No we want to make sure there is only one event
No description provided.