[CLI][WSL2] Windows Terminal freezes while GPT-6 Astra is thinking; animations/title workaround and ETW UIA hotspot

What version of Codex CLI is running?

codex-cli 0.153.4 (Linux x86_64, npm installation).

What subscription do you have?

Not included in this diagnostic report.

Which model were you using?

gpt-6-astra, reasoning effort shown as max.

Regression observed by the user: previously used GPT-5.6 Sol without this problem; after switching to Astra, the terminal repeatedly becomes unresponsive during thinking. This is a historical observation, not a controlled same-version Sol/Astra comparison. Please retain the model-switch correlation during triage; the evidence below does not establish whether the initiating change is model-specific CLI behavior, a CLI regression, Windows Terminal/XAML, or an interaction.

What platform is your computer?

• Windows 11 Insider Preview, build 26220 as recorded in ETW.
• Ubuntu 20.04 on WSL2; Linux Codex CLI launched after entering WSL from PowerShell.
• Project is on the Linux filesystem under the user's home directory, not a Windows-mounted project directory.
• Codex desktop app was also being used for this investigation; its involvement has not been isolated.

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

Windows Terminal file version 1.24.2607.10001, product version 1.24.260710001, verified from the loaded image metadata in the trace.
Hot system module: Windows.UI.Xaml.dll 10.0.26100.9223.

Codex doctor report

The local diagnostic summary reported 19 OK, 1 idle, 0 warnings, 0 failures. Network/authentication/state checks passed. This does not validate interactive terminal responsiveness. Full doctor output is omitted from the public report to avoid exposing local configuration and paths.

What issue are you seeing?

While Astra is thinking, clicking the Terminal window results in long delays before it responds. Typing, scrolling and screen updates also stall; Windows has displayed the window as "Not responding."

Disabling TUI animations and removing the animated title spinner relieved the symptom. Restoring both settings reproduced it, and CPU traces were collected in both conditions.

A separate process CPU observation showed Windows Terminal accumulating roughly 3 seconds of CPU time over a 3-second interval during the stall (approximately one logical core). A contemporaneous WSL CPU observation was almost entirely idle. The measured hotspot is on the Windows Terminal UI thread, rather than simply an inference response taking a long time.

What steps can reproduce the bug?

These steps reproduced the issue in the user's existing long-lived Terminal process/session; a minimal reproduction in a fresh Terminal process is not established.

1. In Windows Terminal, enter WSL and use Codex CLI with gpt-6-astra.
2. With an existing session, enable both animations and the title spinner:

   codex resume --last -m gpt-6-astra -c tui.animations=true -c 'tui.terminal_title=["spinner","project"]'
   

3. While a turn is thinking, click/focus the Terminal and try typing or scrolling. The user confirmed recurrence of the freeze.
4. After safely finishing/stopping the current turn and exiting the CLI, restart with:

   codex resume --last -m gpt-6-astra -c tui.animations=false -c 'tui.terminal_title=["project"]'
   

   The user reported relief with these settings; the baseline trace below was collected with the workaround.

Both flags were changed together and the CLI was restarted, so this does not isolate which flag is necessary or sufficient. The Windows Terminal process remained the same in both recordings.

What is the expected behavior?

The terminal should remain responsive to clicks, typing and scrolling while any supported model is thinking. A working elapsed-time indicator should not require a workaround that disables routine refresh.

With the workaround, the user also observed that Working (3m 49s • esc to interrupt) stopped updating automatically and refreshed on activity. This is a secondary observed behavior, not a claim that inference stopped.

Additional information

ETW CPU evidence

Windows Performance Recorder CPU profile; analyzed with Windows Performance Toolkit 10.0.26100.8249. Each recording was analyzed over the same relative interval, seconds 1–16 (15 seconds). Counts below are SampledProfile events, each with Count=1.

The freeze window had approximately 7.0 times as many Terminal samples and 11.8 times as many GetPattern samples. These are field observations at different times, not an identical-workload benchmark.

Symbolized hotspot

Matching Microsoft public PDB symbols were resolved and the PDB identity checked against the ETW CodeView record and local DLL:
windows.ui.xaml.pdb, GUID C9E8088D-2B8F-4CA4-7E98-486A6B839319, Age 1.

• Function start RVA 0x484ce0: CAutomationPeer::GetPattern.
• Most frequent sampled PC RVA 0x484dcd: CAutomationPeer::GetPattern +0xed (11,453 events in the freeze window).
• Other frequent PCs in the same loop: RVA 0x484dc5 (1,918), 0x484dd4 (234).

Representative main/UI thread call path, caller to callee, with intermediate dispatch and some UIAutomationCore frames omitted:

Windows Terminal UI message dispatch
  -> Microsoft.Terminal.Control.dll
  -> TermControlAutomationPeer RaiseAutomationEvent wrapper
  -> DirectUI::AutomationPeerGenerated::RaiseAutomationEvent
  -> DirectUI::AutomationPeer::RaiseAutomationEventImpl
  -> CCoreServices::UIARaiseAutomationEvent
  -> CUIAWindow::UIARaiseAutomationEvent
  -> UIAutomationCore.dll
  -> CUIAWrapper::GetPatternProvider
  -> CUIAWrapper::GetPatternProviderImpl
  -> CAutomationPeer::GetPattern

Local DLL disassembly shows a linked-node traversal / interface-query loop around RVA 0x484dbd–0x484de1, containing the hottest PCs. Runtime node counts and object lifetimes were not inspected; this does not establish an infinite loop, leak, or corruption.

Open questions for engineering triage

• Is there a model-dependent difference in the CLI's thinking/status/title update path that exposes this problem after switching from Sol to Astra?
• Can periodic redraw/title updates be coalesced without stopping the elapsed-time indicator?
• Which UI Automation client is subscribed? It was not identified, and no attribution to an IME, accessibility client, or the Codex desktop helper has been established.
• Does a completely fresh Windows Terminal process reproduce it? The affected process was long-lived; this has not yet been tested.
• Separate animation-only and title-only tests, and a same-version Sol/Astra comparison, remain outstanding.

Possibly related: #36833 describes UI Automation event pressure involving the desktop computer-use helper, but it concerns a different application/path. It is included as a triage lead, not a confirmed duplicate or attribution.

Raw ETL recordings, private session/code, screenshots, user paths and full logs have not been attached to this public issue. The report was prepared with Codex assistance from local measurements and the user's reproduction observations.

Start with the provided codex resume --last commands in a fresh Windows Terminal process, then compare animations-only and title-spinner-only settings and the Sol/Astra models. Use the existing WPR/ETW interval and Windows Performance Toolkit analysis to verify the UI-thread hotspot. Done means the terminal remains responsive while thinking without disabling the elapsed-time indicator.