fix(tui): scope MCP startup status by thread

[fcoury-oai]

Why

MCP startup failures from spawned subagents were rendered as global notifications, so a child thread's failure could pollute the visible parent transcript. Routing the notification to the child exposed two related replay problems: session refresh could discard the buffered event, and a newly created child ChatWidget did not know the expected MCP server set, which could leave its startup spinner running after every server had settled.

MCP startup diagnostics should remain visible in the thread that owns the startup without affecting other transcripts. The protocol also needs to support a future app-scoped MCP lifecycle where startup is not owned by any thread.

Reported Behavior

The originating Slack report called out that using subagents could turn MCP startup failures into a wall of yellow CLI warnings because repeated failures were not deduplicated. The intended behavior is for those diagnostics to remain visible once in the thread that owns the startup, without polluting the parent transcript.

What Changed

• add nullable threadId ownership to mcpServer/startupStatus/updated
• populate it from the app-server conversation ID for the current thread-scoped lifecycle and regenerate the protocol schema and TypeScript artifacts
• treat a missing or null threadId as app-scoped without injecting it into the active chat transcript
• route and buffer thread-owned MCP startup notifications by thread in the TUI
• preserve buffered MCP startup events across child session refresh
• seed expected MCP servers before replaying a thread snapshot so startup reaches its terminal state
• suppress an identical repeated failure warning for the same server within one startup round

The owning thread still renders the detailed failure and final MCP startup incomplete (...) summary.

How to Test

Child-owned failure

1. Configure a stateful optional MCP server named smoke whose first launch succeeds and subsequent launches fail during initialization.
2. Launch the TUI with multi-agent support enabled and confirm the primary thread starts without an MCP warning.
3. Spawn exactly one subagent and confirm the parent transcript still has no smoke warning or incomplete-startup summary.
4. Confirm the fixture recorded two MCP launches, proving both the parent and child attempted startup.
5. Switch to the subagent thread and confirm it contains exactly one detailed smoke failure and one MCP startup incomplete (failed: smoke) summary.
6. Switch between the parent and subagent and confirm the warnings neither move nor duplicate, and no MCP startup spinner remains.

Primary-owned failure

1. Relaunch with the fixture already configured to fail.
2. Confirm the primary transcript contains exactly one detailed smoke failure and one incomplete-startup summary.

Targeted tests:

• just test -p codex-app-server-protocol
• just test -p codex-app-server thread_start_emits_mcp_server_status_updated_notifications
• just test -p codex-tui mcp_startup

Both manual paths were exercised in tmux on commit 1b50304606. The child-owned run kept the parent warning-free across thread switches, rendered the child diagnostics once, and left no stale startup spinner. just argument-comment-lint was attempted locally but blocked by an unrelated Bazel LLVM empty-glob failure; the corresponding CI checks passed.

[chatgpt-codex-connector]

💡 Codex Review

Here are some automated review suggestions for this pull request.

Reviewed commit: b5eae73269

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

[fcoury-oai]

@codex review

[chatgpt-codex-connector]

💡 Codex Review

Here are some automated review suggestions for this pull request.

Reviewed commit: 84b8997c6c

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

[fcoury-oai]

@codex review

[chatgpt-codex-connector]

Codex Review: Didn't find any major issues. Another round soon, please!

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

[fcoury-oai]

@etraut-openai ready for re-review at your convenience.

[etraut-openai]

Looks good. Code is much simpler than before!

I had codex manually test this by creating a bad MCP config.