CLI terminal title can remain overwritten after MCP or shell activity

What version of Codex CLI is running?

codex-cli 0.142.2

What subscription do you have?

ChatGPT plan

Which model were you using?

Not model-specific.

What platform is your computer?

Microsoft Windows NT 10.0.26200.0 x64

What terminal emulator and version are you using (if applicable)?

VS Code integrated terminal on Windows, using PowerShell/CMD shells.

Codex doctor report

I ran the local checks used for this report, but I am not pasting the full raw codex doctor --json output because it can include local paths/config details. I can provide a redacted doctor report if useful.

Relevant user config shape:

[tui]
terminal_title = ["app-name", "thread", "project"]

What issue are you seeing?

When Codex CLI is configured to manage the terminal title, the title can initially be correct, then later be overwritten by external activity such as MCP startup/inventory/tool activity or shell command execution.

One visible example is a VS Code integrated terminal tab/window title that starts as a Codex/project or Codex/thread title, but after MCP inventory or MCP activity settles, the terminal title remains set to an MCP/server/process-derived title such as a browser/devtools MCP label. The same class of problem can happen after shell command activity changes the terminal title.

This appears to happen because Codex caches the last title it wrote and skips redundant writes when the computed managed title is unchanged. If a child process, MCP server, shell, or other external activity changes the visible terminal title outside that cache, the next ordinary Codex refresh can decide there is nothing to write, leaving the visible terminal title stale/incorrect.

Related broader feature request: #21958. This report is narrower: Codex already has terminal-title configuration, but the managed title is not reliably reasserted after external activity overwrites the visible terminal title.

What steps can reproduce the bug?

1. Configure Codex CLI to manage the terminal title, for example:

``toml
[tui]
terminal_title = ["app-name", "thread", "project"]
``

1. Start Codex CLI in a project from VS Code integrated terminal on Windows.
2. Observe that the terminal title is initially managed by Codex.
3. Trigger MCP-related activity, for example open /mcp so Codex loads MCP inventory, or use an MCP tool/server that changes the process-visible terminal title while it starts/runs.
4. Observe the terminal title after the activity settles.

What is the expected behavior?

Codex should reassert its managed terminal title after external activity boundaries settle.

For example:

• If the thread/session has a title, keep showing the configured Codex/thread title.
• If no thread/session title exists, keep showing the configured project fallback/title items.
• MCP startup, MCP inventory loading, MCP tool calls, and shell command execution should not leave the terminal title stuck on a child process/server/shell title.

Additional information

I have a small focused branch that demonstrates one possible fix with tests:

https://github.com/arindamroy-oss/codex/tree/fix-terminal-title-after-mcp-startup

Commit: 81b2eeb59f10e65fe2acae50f63ff8ff39c502d8

High-level approach in that branch:

• Add a forced terminal-title refresh path that re-emits the last managed Codex title even if the computed title text is unchanged.
• Call that forced refresh after MCP startup settles, MCP inventory loading completes, live MCP tool calls start/complete, and live command execution starts/completes.
• Avoid special-casing any MCP server by name.
• Add a thread-title-or-project title item so users can express "use thread title when available, otherwise project" as one stable title segment.

Local checks run on the branch:

cargo test -p codex-tui terminal_title --lib -j 1
cargo test -p codex-tui mcp_startup --lib -j 1
cargo test -p codex-tui handle_mcp_inventory --lib -j 1
cargo test -p codex-tui slash_mcp --lib -j 1
cargo test -p codex-cli --bin codex doctor::title -j 1
cargo build -p codex-cli --bin codex -j 1
cargo fmt --check

Known local tooling caveat:

• just was not installed in my local Windows shell, so I used direct Cargo commands.
• Scoped cargo clippy attempts timed out locally, so I am not claiming Clippy passed.

Per the contribution guidelines, I am opening this issue first rather than opening an unsolicited PR. If maintainers agree this is the right direction, I am happy to open a focused PR from the branch above.