macOS desktop follow-up message submit delayed 5-10s after Computer Use update

Description

After updating the Codex macOS app to the release that included the Computer Use plugin, message submission in the desktop app became much slower.

The first user message in a brand-new conversation usually submits normally. The problem starts on subsequent turns:

1. I start a new Codex conversation in the Mac application.
2. I send a first message. That message enters the chat normally.
3. Codex responds.
4. I type a follow-up message and press Enter.
5. Instead of the message being sent immediately, I see the submit spinner/loading state for about 5 to 10 seconds before Codex actually receives the message.

Sometimes it is even worse:

• the UI feels very sluggish while trying to send
• the message appears not to register at first
• the spinner can keep spinning until I click around the interface, after which it may eventually send

Before this update, sending messages in the desktop app felt extremely fast. This regression started only after updating to the version that added the Computer Use plugin. I did not have this behavior before April 16, 2026.

What version of the Codex App are you using (From "About Codex" dialog)?

26.415.32059 (1789)

What subscription do you have?

Pro

What platform is your computer?

• macOS 26.2 (25C56)
• Darwin 25.2.0
• arm64

What issue are you seeing?

The desktop app's message submit path is delayed on follow-up turns after the assistant has already responded in the thread.

Concrete symptom:

• first message in a fresh thread is usually fine
• after the assistant replies, the next message submit is delayed by ~5-10 seconds
• the submit spinner is visible during that delay
• the UI feels sluggish while waiting for the message to actually register

This feels specifically like a desktop app / app-server / plugin-runtime regression, not normal model latency, because the delay happens before the next user message is actually accepted and sent.

What steps can reproduce the bug?

1. Open Codex Desktop on macOS.
2. Start a new conversation.
3. Send an initial prompt.
4. Wait for the assistant response.
5. Type a follow-up prompt and press Enter.
6. Observe that the UI can sit in a loading/spinning state for about 5-10 seconds before the follow-up message is actually submitted.
7. Repeat on later turns and the lag persists.

What is the expected behavior?

Submitting a follow-up user message should be immediate or near-immediate, as it was before this update.

The desktop app should not spend 5-10 seconds in a loading state before the message is even accepted into the conversation.

Additional information

I did some local debugging and found signals that seem relevant:

• Local app state shows the desktop renderer and app-server are busy enough to matter while this happens.
• Local logs show repeated plugin-manifest warnings during submission dispatch:
• codex_core::plugins::manifest: ignoring interface.defaultPrompt: prompt must be at most 128 characters
• codex_core::plugins::manifest: ignoring interface.defaultPrompt: maximum of 3 prompts is supported
• Local logs also show:
• codex_tui::app::app_server_adapter: app-server event consumer lagged; dropping ignored events
• I also found many SkyComputerUseClient helper processes and a large local session/history footprint, which may be amplifying the problem.

I initially suspected my custom conversation-status hooks, because I have local hooks that drive my lights based on Codex state. But timing the hook command directly suggests it is not the main cause:

• the UserPromptSubmit hook command itself completes in about 14ms when run directly
• it has a hard curl --max-time 0.4 timeout

So while custom hooks may add a little overhead, they do not explain a 5-10 second submit delay by themselves.

This issue looks related to the recent desktop / Computer Use rollout. These may be related:

• #18333
• #11984
• #13709

If useful, I can also provide:

• exact local log excerpts from ~/.codex/log/codex-tui.log
• local process snapshots showing repeated SkyComputerUseClient helpers
• local state/log DB details