Codex Desktop App freezes on the second message #44590

Activity

1. faelp22

   added

   appIssues related to the Codex desktop appIssues related to the Codex desktop app

   on Sep 10, 2026
2. github-actions

   added

   bugSomething isn't workingSomething isn't working

   windows-osIssues related to Codex on Windows systemsIssues related to Codex on Windows systems

   on Sep 10, 2026
3. github-actions

   changed the title [-]App Desktop Codex travamento na segunda mensagem[/-] [+]Codex Desktop App freezes on the second message[/+] on Sep 10, 2026
4. github-actions commented on Sep 10, 2026

   

   github-actionsBot

   on Sep 10, 2026 – with GitHub Actions

   Contributor

   More actions

   English translation:

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

   26.903.9818.0

   What subscription do you have?

   plus

   What platform is your computer?

   Windows 11 x64

   What issue are you seeing?

   I can only send one message. On the second interaction, the app's send button keeps spinning, so I have to open a new chat. This problem started a few weeks ago, and today it got so much worse that it became impossible to work.

   diagnostico-travamento-codex.txt

   diagnostico-complementar-codex.txt

   What steps can reproduce the bug?

   I have no idea. I simply send a Hi, and then when I try to say something else, the message won't send.

   What is the expected behavior?

   

   Additional information

   Chat Feedback ID
   01a08c40-3796-7621-851a-0ef96bdffb9d

   01a08c4d-34af-76e3-ab96-dbf0d16e2b49
5. github-actions commented on Sep 10, 2026

   

   github-actionsBot

   on Sep 10, 2026 – with GitHub Actions

   Contributor

   More actions

   Potential duplicates detected. Please review them and close your issue if it is a duplicate.

   • Windows Desktop 26.903.61454: follow-up messages cannot be sent after the first completed turn #44102
   • Windows desktop app: second/follow-up message hangs indefinitely in Work and Codex after Sep 5 update #43366
   • [Windows Desktop] Second message stalls after first turn completes #44295

   Powered by Codex Action
6. faelp22

   closed this as a duplicateof Windows Desktop 26.903.61454: follow-up messages cannot be sent after the first completed turn #44102 on Sep 10, 2026
7. faelp22 commented on Sep 17, 2026

   

   faelp22

   on Sep 17, 2026

   Last edited by faelp22

   Author

   More actions

   Update: I found the cause in my case

   I wanted to share an update because this may help other users experiencing the same Codex Desktop freeze.

   In my environment, the issue was related to an external MCP server used by Codex Desktop.

   My setup is:

   Spring Boot 4.1.1
   Spring AI 2.0.1
   MCP Server: STATELESS
   Spring MVC
   PostgreSQL
   Codex Desktop on multiple Windows/macOS machines
   

   The important detail is that I was already using STATELESS before the problem was fixed, and I am still using STATELESS now.

   So, in my case, switching from STATELESS to STREAMABLE was not necessary.

   Previous configuration

   Initially, my MCP server was configured approximately like this:

   spring:
     ai:
       mcp:
         server:
           protocol: STATELESS
           type: SYNC
           capabilities:
             resource: false
             tool: true
             prompt: false
             completion: false

   At that time, Spring AI 2.0.1 was resolving MCP Java SDK 2.0.0.

   Codex Desktop still performed requests/probes such as:

   resources/list
   resources/templates/list
   notifications/initialized
   

   The MCP server logs showed:

   WARN DefaultMcpStatelessServerHandler
   Missing handler for notification type: notifications/initialized
   

   and:

   ERROR WebMvcStatelessServerTransport
   Failed to handle request:
   Missing handler for request type: resources/templates/list
   

   and:

   ERROR WebMvcStatelessServerTransport
   Failed to handle request:
   Missing handler for request type: resources/list
   

   This correlated with Codex Desktop conversations becoming stuck.

   In some conversations, the first interaction would complete successfully, but later messages could remain indefinitely in a busy/spinning state.

   MCP Java SDK bug

   The main issue appears to have been the behavior of MCP Java SDK 2.0.0 in STATELESS mode when receiving a request for which no handler was registered.

   Instead of cleanly returning the expected JSON-RPC error, such as:

   -32601 Method not found
   

   the missing handler could propagate as an HTTP transport failure / HTTP 500.

   This is documented in the MCP Java SDK:

   • modelcontextprotocol/java-sdk#784
   • fixed by modelcontextprotocol/java-sdk#800
   • released in MCP Java SDK 2.0.1

   There is also a Spring AI issue related to the SDK dependency version:

   • spring-projects/spring-ai#6998

   What I changed

   I kept:

   Spring AI 2.0.1
   protocol = STATELESS
   type = SYNC
   

   but upgraded/overrode the MCP Java SDK from:

   MCP Java SDK 2.0.0
   

   to:

   MCP Java SDK 2.0.1
   

   I also changed my MCP capabilities so that they are now all enabled:

   spring:
     ai:
       mcp:
         server:
           protocol: STATELESS
           type: SYNC
           capabilities:
             resource: true
             tool: true
             prompt: true
             completion: true

   So the current working configuration is:

   Spring AI 2.0.1
   MCP Java SDK 2.0.1
   protocol = STATELESS
   resource = true
   prompt = true
   completion = true
   tool = true
   

   Result

   After these changes:

   • resources/list stopped producing the HTTP 500 error
   • resources/templates/list stopped producing the HTTP 500 error
   • the notifications/initialized missing-handler warning disappeared
   • Codex Desktop stopped freezing in my tests
   • conversations that were previously stuck started working again
   • I was able to continue sending follow-up messages normally
   • I did not need to migrate the server from STATELESS to STREAMABLE

   One particularly interesting result was that some already-stuck conversations started working again after the MCP server was updated.

   Maven note for Spring AI 2.0.1 users

   In my dependency tree, Spring AI 2.0.1 was still resolving MCP Java SDK 2.0.0.

   I explicitly aligned the MCP SDK to 2.0.1 using its BOM:

   <properties>
       <spring-ai.version>2.0.1</spring-ai.version>
       <mcp-sdk.version>2.0.1</mcp-sdk.version>
   </properties>
   
   <dependencyManagement>
       <dependencies>
   
           <dependency>
               <groupId>io.modelcontextprotocol.sdk</groupId>
               <artifactId>mcp-bom</artifactId>
               <version>${mcp-sdk.version}</version>
               <type>pom</type>
               <scope>import</scope>
           </dependency>
   
           <dependency>
               <groupId>org.springframework.ai</groupId>
               <artifactId>spring-ai-bom</artifactId>
               <version>${spring-ai.version}</version>
               <type>pom</type>
               <scope>import</scope>
           </dependency>
   
       </dependencies>
   </dependencyManagement>

   Then I verified the actual resolved versions with:

   mvn dependency:tree -Dincludes=io.modelcontextprotocol.sdk

   to make sure all MCP Java SDK modules were using 2.0.1.

   Important clarification

   I cannot say with certainty that enabling:

   resource = true
   prompt = true
   completion = true
   

   was independently responsible for fixing the problem.

   Two things changed in my environment:

   1. MCP Java SDK 2.0.0 -> 2.0.1
   2. resource/prompt/completion false -> true
   

   However, the HTTP 500 behavior I was seeing matches a known bug in MCP Java SDK 2.0.0, and that bug was explicitly fixed in 2.0.1.

   The key point is that STATELESS itself was not the issue, because my server was STATELESS both before and after the fix.

   My current working setup is still:

   Codex Desktop
         |
         | HTTP
         v
   Spring AI MCP Server
   STATELESS
         |
         v
   PostgreSQL
   

   Possible Codex-side robustness issue

   There may still be a Codex-side robustness issue worth investigating.

   An external MCP server returning an unexpected HTTP 500 during an optional MCP probe should ideally surface an MCP error and allow the conversation to continue.

   It probably should not leave the entire Codex conversation permanently stuck in a busy/streaming state.

   So even though updating the MCP Java SDK fixed the problem for me, Codex may benefit from more defensive handling when an MCP server fails during capability discovery or initialization.

   For anyone using Spring AI / Java MCP servers and seeing similar Codex freezes, I would recommend checking the MCP server logs for:

   Missing handler for request type: resources/list
   Missing handler for request type: resources/templates/list
   Missing handler for notification type: notifications/initialized
   

   and checking the actual resolved MCP Java SDK version.

   In my case, the combination that is currently stable is:

   Spring AI 2.0.1
   MCP Java SDK 2.0.1
   STATELESS
   resource = true
   prompt = true
   completion = true
   tool = true
   

   and Codex Desktop has remained stable so far.
8. faelp22 commented on Sep 17, 2026

   

   faelp22

   on Sep 17, 2026

   Author

   More actions

   I posted more details about this bug at: #44102 #29376