Show approval requests as a composer waiting state#22
Merged
friuns2 merged 2 commits intofriuns2:devfrom Apr 3, 2026
Merged
Conversation
What changed: - schedule one follow-up sync a few seconds after a successful turn/start - clear pending delayed sync timers when polling stops Why: - upstream/main only refreshed immediately after turn/start, so approval option 3 could send the message correctly but miss the later thread/read materialization window Impact: - normal send flow now picks up user messages that appear a couple of seconds later without waiting for a manual refresh Validation: - npm run build - CODEXUI_BASE_URL=http://127.0.0.1:4180 node output/playwright/verify-bug-032-approval-panel.mjs
Review Summary by QodoShow approval requests as composer waiting state with delayed sync
WalkthroughsDescription• Move approval requests from chat history to dedicated composer panel • Add delayed thread sync after turn/start for follow-up message materialization • Display pending request state badges in sidebar thread list • Support freeform feedback through normal message flow instead of approval payload Diagramflowchart LR
A["Pending Server Request"] --> B["readPendingRequestState"]
B --> C["UiPendingRequestState"]
C --> D["applyThreadFlags"]
D --> E["UiThread with pendingRequestState"]
E --> F["Sidebar Badge"]
E --> G["ThreadPendingRequestPanel"]
G --> H["User Response"]
H --> I["respondToPendingServerRequest"]
I --> J["scheduleDelayedTurnSync"]
J --> K["Follow-up Message Materialization"]
H --> L["followUpMessageText"]
L --> M["sendMessageToSelectedThread"]
File Changes1. src/composables/useDesktopState.ts
|
Code Review by Qodo
1. ESM import in Playwright script
|
![qodo-code-review[bot]](https://avatars.githubusercontent.com/in/484649?s=60&v=4){kind=small}
| @@ -0,0 +1,592 @@ | |||
| import { chromium } from 'playwright' | |||
There was a problem hiding this comment.
1. Esm import in playwright script 📘 Rule violation ⚙ Maintainability
The new Playwright verification script uses an ESM import instead of the repository-default CommonJS require(...) style without any explicit ESM requirement. This violates the Playwright automation script module-format compliance requirement and can reduce consistency/compatibility with the repo’s tooling expectations.
Agent Prompt
## Issue description
A new Playwright automation script uses ESM `import` syntax, but repo compliance requires CommonJS `require(...)` by default unless ESM is explicitly required.
## Issue Context
The file is `output/playwright/verify-bug-032-approval-panel.mjs` and begins with an ESM import from `playwright`.
## Fix Focus Areas
- output/playwright/verify-bug-032-approval-panel.mjs[1-1]
## Implementation notes
- Replace `import { chromium } from 'playwright'` with `const { chromium } = require('playwright')`.
- Since CommonJS doesn’t support top-level `await` in most setups, wrap the async entrypoint in an async IIFE (e.g., `(async () => { ... })().catch(...)`).
- Optionally rename the script to `.cjs` (or `.js` if the repo treats it as CJS) to avoid ambiguity.
ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools
Comment on lines
+589
to
+592
| const selectedThreadPendingRequest = computed<UiServerRequest | null>(() => { | ||
| const rows = selectedThreadServerRequests.value | ||
| return rows.length > 0 ? rows[rows.length - 1] : null | ||
| }) |
There was a problem hiding this comment.
2. Pending request ordering wrong 🐞 Bug ✓ Correctness
App.vue selects the newest pending server request (last element) for the composer waiting panel even though pending requests are sorted oldest→newest. If multiple pending requests exist, earlier requests become unreachable (panel shows only one), potentially leaving the thread blocked waiting for an older request to be answered.
Agent Prompt
### Issue description
The active pending request shown in the composer waiting panel is chosen as the newest request (`rows[rows.length - 1]`), even though pending requests are sorted oldest→newest. This can hide older pending requests entirely, preventing users from responding to them and potentially blocking progress.
### Issue Context
- `selectedThreadServerRequests` is sorted ascending by `receivedAtIso`.
- The new `ThreadPendingRequestPanel` renders only a single request; it does not offer a way to select older pending requests.
### Fix Focus Areas
- src/App.vue[589-592]
- src/composables/useDesktopState.ts[718-728]
### Suggested fix
- Change selection to the oldest request (`rows[0]`) to honor FIFO.
- If you intentionally want “most recent wins”, add UI affordances to access/respond to older pending requests (e.g., a list/stepper) or explicitly filter to the single truly-active request from the backend.
ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools
friuns2
pushed a commit
that referenced
this pull request
Apr 3, 2026
Adds ThreadPendingRequestPanel component that replaces the composer when server requests (tool approvals) are pending, providing a dedicated UI for reviewing and responding to approval requests. Made-with: Cursor
Owner
|
Merged into dev branch manually. |
Review Summary by QodoShow approval requests as a composer waiting state WalkthroughsDescription• Replace approval request chat cards with dedicated composer panel • Add sidebar badges showing pending approval/response states • Send freeform feedback through normal message flow instead of approval payload • Schedule delayed thread sync after turn materialization for follow-up messages Diagramflowchart LR
A["Pending Server Request"] --> B["ThreadPendingRequestPanel"]
B --> C["Approval Options"]
B --> D["Freeform Input"]
C --> E["Respond to Request"]
D --> E
E --> F["Send Follow-up Message"]
F --> G["Delayed Sync"]
G --> H["Message Materialization"]
A --> I["Sidebar Badge"]
I --> J["Visual State Indicator"]
File Changes1. src/App.vue
|
Code Review by Qodo
1. ESM import in Playwright script
|
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
This brings the desktop approval-request waiting state into CodexUI so approval prompts no longer render as chat history cards at the top of the thread.
What changed:
ThreadPendingRequestPanelwith compact approval controls that match the Codex Desktop flow3through the normal message flow instead of packing it into the approval payloadturn/startsync so follow-up user messages still materialize whenthread/readlags by a couple of secondsWhy
Codex Desktop treats approvals as an explicit waiting state anchored to the bottom composer area. On the web side, CodexUI was surfacing the same requests as normal chat cards, which made the waiting state easy to miss and broke parity with the desktop interaction model.
The delayed sync follow-up keeps the option
3flow honest on top ofupstream/main: the message is still sent through the normalturn/startpath, but CodexUI now retries one refresh after the server-side message materialization window instead of requiring a manual refresh.Testing
npm run buildCODEXUI_BASE_URL=http://127.0.0.1:4176 node output/playwright/verify-bug-032-approval-panel.mjsScreenshot