Windows app stutters when switching chats or opening Settings #30428

Activity

1. github-actions

   added

   bugSomething isn't workingSomething isn't working

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

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

   app-serverIssues involving app server protocol or interfacesIssues involving app server protocol or interfaces

   performance

   on Jun 28, 2026
2. github-actions commented on Jun 28, 2026

   

   github-actionsbot

   on Jun 28, 2026 – with GitHub Actions

   Contributor

   More actions

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

   • Windows Desktop UI stutters on launch, new chat, first typing, and Settings #29821
   • Windows Desktop leaves repeated/stuck git.exe polling processes in multi-repo workspace #29408
   • Windows Desktop background Git probes can create CPU/I/O storms via conhost and AV scanning #30345
   • Windows 10 app 26.616.4196.0 repeatedly spawns Git root/metadata probes while idle #29110

   Powered by Codex Action
3. kangmingxuan

   changed the title [-]Codex Windows app UI stutters when switching conversations or opening Settings; WPR shows 38s UI delay plus Git/node_repl churn[/-] [+]Windows app stutters when switching chats or opening Settings[/+] on Jun 28, 2026
4. kangmingxuan commented on Jun 28, 2026

   

   kangmingxuan

   on Jun 28, 2026 – with ChatGPT Codex Connector

   Author

   More actions

   Additional source-code correlation and proposed fix

   I did another pass comparing the WPR traces with the public source at bdd282f3bbd55df3a869a5438519cd948c134d4d.

   The highest-confidence hypothesis is that latency-sensitive desktop UI paths are hitting local thread listing / metadata repair / Git enrichment work, rather than a general CPU saturation issue.

   Relevant source paths:

   • ThreadListParams.useStateDbOnly defaults to false, and the protocol comment says false preserves JSONL rollout scan-and-repair behavior:
     

     codex/codex-rs/app-server-protocol/src/protocol/v2/thread.rs

     Lines 1099 to 1103 in bdd282f

     	/// If true, return from the state DB without scanning JSONL rollouts to
     	/// repair thread metadata. Omitted or false preserves scan-and-repair
     	/// behavior.
     	#[serde(default, skip_serializing_if = "std::ops::Not::not")]
     	pub use_state_db_only: bool,

   • thread/list passes useStateDbOnly through to the thread store:
     

     codex/codex-rs/app-server/src/request_processors/thread_processor.rs

     Lines 1907 to 1966 in bdd282f

     	async fn thread_list_response_inner(
     	&self,
     	params: ThreadListParams,
     	) -> Result<ThreadListResponse, JSONRPCErrorError> {
     	let ThreadListParams {
     	cursor,
     	limit,
     	sort_key,
     	sort_direction,
     	model_providers,
     	source_kinds,
     	archived,
     	cwd,
     	use_state_db_only,
     	search_term,
     	parent_thread_id,
     	ancestor_thread_id,
     	} = params;
     	let cwd_filters = normalize_thread_list_cwd_filters(cwd)?;
     	let relation_filter = match (parent_thread_id, ancestor_thread_id) {
     	(Some(_), Some(_)) => {
     	return Err(invalid_request(
     	"parentThreadId and ancestorThreadId are mutually exclusive",
     	));
     	}
     	(Some(parent_thread_id), None) => Some(StoreThreadRelationFilter::DirectChildrenOf(
     	ThreadId::from_string(&parent_thread_id)
     	.map_err(|err| invalid_request(format!("invalid parent thread id: {err}")))?,
     	)),
     	(None, Some(ancestor_thread_id)) => Some(StoreThreadRelationFilter::DescendantsOf(
     	ThreadId::from_string(&ancestor_thread_id)
     	.map_err(|err| invalid_request(format!("invalid ancestor thread id: {err}")))?,
     	)),
     	(None, None) => None,
     	};
     	let requested_page_size = limit
     	.map(|value| value as usize)
     	.unwrap_or(THREAD_LIST_DEFAULT_LIMIT)
     	.clamp(1, THREAD_LIST_MAX_LIMIT);
     	let store_sort_key = match sort_key.unwrap_or(ThreadSortKey::CreatedAt) {
     	ThreadSortKey::CreatedAt => StoreThreadSortKey::CreatedAt,
     	ThreadSortKey::UpdatedAt => StoreThreadSortKey::UpdatedAt,
     	ThreadSortKey::RecencyAt => StoreThreadSortKey::RecencyAt,
     	};
     	let sort_direction = sort_direction.unwrap_or(SortDirection::Desc);
     	let (stored_threads, next_cursor) = self
     	.list_threads_common(
     	requested_page_size,
     	cursor,
     	store_sort_key,
     	sort_direction,
     	ThreadListFilters {
     	model_providers,
     	source_kinds,
     	archived: archived.unwrap_or(false),
     	cwd_filters,
     	search_term,
     	use_state_db_only,
     	relation_filter,

   • The local thread store uses the state DB fast path only when use_state_db_only is true; otherwise it falls back to rollout scanning:
     

     codex/codex-rs/thread-store/src/local/list_threads.rs

     Lines 151 to 209 in bdd282f

     	let page = if params.use_state_db_only && params.archived {
     	RolloutRecorder::list_archived_threads_from_state_db(
     	state_db,
     	config,
     	params.page_size,
     	cursor,
     	sort_key,
     	sort_direction,
     	params.allowed_sources.as_slice(),
     	params.model_providers.as_deref(),
     	params.cwd_filters.as_deref(),
     	default_model_provider_id,
     	params.search_term.as_deref(),
     	)
     	.await
     	} else if params.use_state_db_only {
     	RolloutRecorder::list_threads_from_state_db(
     	state_db,
     	config,
     	params.page_size,
     	cursor,
     	sort_key,
     	sort_direction,
     	params.allowed_sources.as_slice(),
     	params.model_providers.as_deref(),
     	params.cwd_filters.as_deref(),
     	default_model_provider_id,
     	params.search_term.as_deref(),
     	)
     	.await
     	} else if params.archived {
     	RolloutRecorder::list_archived_threads(
     	state_db,
     	config,
     	params.page_size,
     	cursor,
     	sort_key,
     	sort_direction,
     	params.allowed_sources.as_slice(),
     	params.model_providers.as_deref(),
     	params.cwd_filters.as_deref(),
     	default_model_provider_id,
     	params.search_term.as_deref(),
     	)
     	.await
     	} else {
     	RolloutRecorder::list_threads(
     	state_db,
     	config,
     	params.page_size,
     	cursor,
     	sort_key,
     	sort_direction,
     	params.allowed_sources.as_slice(),
     	params.model_providers.as_deref(),
     	params.cwd_filters.as_deref(),
     	default_model_provider_id,
     	params.search_term.as_deref(),
     	)

   • The Git metadata path runs short-lived Git commands such as status --porcelain, remote -v, and rev-parse HEAD:
     

     codex/codex-rs/git-utils/src/info.rs

     Lines 291 to 300 in bdd282f

     	pub async fn get_has_changes(cwd: &Path) -> Option<bool> {
     	let git = Path::new("git");
     	let fsmonitor = detect_local_fsmonitor_override(git, cwd).await;
     	let output =
     	run_git_command_with_timeout_from(git, &["status", "--porcelain"], cwd, fsmonitor).await?;
     	if !output.status.success() {
     	return None;
     	}
     	Some(!output.stdout.is_empty())

     
     

     codex/codex-rs/core/src/turn_metadata.rs

     Lines 315 to 320 in bdd282f

     	async fn fetch_workspace_git_metadata(&self) -> WorkspaceGitMetadata {
     	let (head_commit_hash, associated_remote_urls, has_changes) = tokio::join!(
     	get_head_commit_hash(&self.cwd),
     	get_git_remote_urls_assume_git_repo(&self.cwd),
     	get_has_changes(&self.cwd),
     	);

   • core.fsmonitor is intentionally probed every time:
     

     codex/codex-rs/git-utils/src/fsmonitor.rs

     Lines 42 to 59 in bdd282f

     	/// Returns the safe filesystem monitor override for the target repository.
     	///
     	/// This intentionally probes every time. Effective Git configuration is
     	/// layered, may use conditional includes, and can change while Codex is
     	/// running:
     	/// https://git-scm.com/docs/git-config#SCOPES
     	/// https://git-scm.com/docs/git-config#_conditional_includes
     	pub async fn detect_fsmonitor_override(
     	runner: &mut impl FsmonitorProbeRunner,
     	) -> FsmonitorOverride {
     	// A typed query converts every matching value before `--get` selects the
     	// effective one. A shadowed helper path can therefore make a repository-
     	// local true fail conversion. Query the raw effective value first.
     	// https://github.com/git/git/blob/94f057755b7941b321fd11fec1b2e3ca5313a4e0/builtin/config.c#L482-L514
     	// https://github.com/git/git/blob/94f057755b7941b321fd11fec1b2e3ca5313a4e0/builtin/config.c#L611-L614
     	let Some(config) = runner
     	.run_probe(&["config", "--null", "--get", "core.fsmonitor"])
     	.await

   This matches the WPR traces: Codex.exe shows long UI delays while system CPU remains mostly idle, and the trace contains many short-lived git.exe processes with status --porcelain, remote -v, rev-parse HEAD, and config --null --get core.fsmonitor.

   Proposed fix:

   For latency-sensitive Windows desktop UI paths such as chat switching, sidebar history refresh, and entering Settings, call thread/list with useStateDbOnly: true. Move JSONL rollout metadata repair and Git enrichment to a background, batched, or idle-time path, then refresh the UI when repaired metadata is available.

   A second useful optimization would be to cache or dedupe Git metadata probes per repo root for a short TTL, especially git status --porcelain and the repeated core.fsmonitor probe.

   This may be Windows-amplified rather than Windows-only: the same app-server paths are cross-platform, but Git-for-Windows process startup, NTFS metadata access, Defender scanning, and the Windows desktop shell make repeated short-lived Git probes more visible as UI stalls.
5. areslp commented on Jul 18, 2026

   

   areslp

   on Jul 18, 2026 – with ChatGPT Codex Connector

   More actions

   Follow-up from the current Windows release with a source-level correlation.

   Current build

   • Microsoft Store package: OpenAI.Codex_26.715.4045.0_x64__2p2nqsd0c76g0
   • Desktop release: 26.715.31925
   • Bundled app-server: 0.145.0-alpha.18
   • Windows 11 x64

   The update made the recurring system-wide stutter substantially worse. The Corsair K70 is still in BIOS mode, reducing the observed composite USB/HID nodes from 8 to 2, but that workaround is no longer enough.

   Git process evidence

   A narrow watchdog observed Codex-owned Git processes from 19:27:58 through 21:06:55 and terminated only processes older than 3 seconds. It recorded 623 process rows (including the Git-for-Windows wrapper and real child process as separate rows):

   • 241 × rev-parse HEAD
   • 237 × remote -v
   • 81 × status --porcelain
   • additional rev-parse --git-dir / fsmonitor probes

   Immediately after the 4045 package started, the 20:55–20:59 window alone produced 56 such >3-second rows in minute-like bursts.

   Running the same Git commands manually in the same repository took only 32–46 ms, so this is not an intrinsically slow repository or Git installation.

   No new WER AppHangTransient or Application Hang event 1002 was recorded during these short recurring stalls. That means formal Windows hang telemetry misses this failure mode even while the app and mouse visibly stutter.

   Public source correlation

   The bundled Rust app-server path collects rev-parse HEAD, remote -v, and status --porcelain together for turn workspace metadata. Its five-second timeout currently uses Tokio kill_on_drop(true), which terminates only the directly spawned wrapper.

   Open PR #30235 documents the exact residual-child mechanism: if git resolves to a wrapper, the wrapped Git process can keep scanning after the timeout. However, that PR only adds Unix process-group cleanup; the Windows path still has no equivalent process-tree termination.

   A Windows-specific fix should retain the child until timeout, run hidden taskkill /PID <pid> /T /F, and reap the wrapper/output future. The existing exec-server already uses taskkill /T /F for Windows stdio process trees, so this would follow an established repository pattern rather than introduce a new platform mechanism.

   I have a focused patch and regression test locally; local codex-git-utils tests pass (27/27), and the Windows-only Tokio code cross-checks successfully.
6. areslp commented on Jul 18, 2026

   

   areslp

   on Jul 18, 2026

   More actions

   Follow-up: I now have a focused implementation available at areslp@b8d7f3c

   It adds Windows-specific timeout cleanup for the entire wrapped process tree for all Git metadata probes, plus a regression test that verifies a wrapped child cannot survive the timeout.

   Validation completed:

   • just test -p codex-git-utils: 27/27 passed
   • just fix -p codex-git-utils
   • just fmt
   • Windows target compile check passed
   • Native win-l taskkill /T /F semantics test confirmed parent and child processes were gone and the delayed marker was never written

   The repository contribution guide says external PRs are by invitation only, so I have not opened an unsolicited PR. If maintainers agree with this approach, please invite me to submit it and I can open the PR immediately.
7. areslp commented on Jul 20, 2026

   

   areslp

   on Jul 20, 2026 – with ChatGPT Codex Connector

   More actions

   Follow-up after updating the same Windows installation to the July 20 Store package.

   Current build and HID control

   • Microsoft Store package: OpenAI.Codex_26.715.7063.0_x64__2p2nqsd0c76g0
   • Windows 11 x64
   • Corsair K70 restored to normal composite mode: 8 present USB/HID nodes
   • concurrent_reasoning_summaries = false remains configured

   The HID/main-thread regression appears improved in this build. During a 45.78-second read-only external sample, the main window was responsive in 131/131 checks, with zero Responding=False samples and no new Application Hang event 1002. This is only a short smoke result, but it matches the positive 7063/52143 reports in #33780/#33884.

   Git process storm still reproduces

   The same sample did not execute Git itself, but observed:

   • 33 distinct git.exe PIDs
   • peak concurrent Git count: 24
   • 169 sampled Git process rows
   • repeated commands remained status --porcelain, rev-parse HEAD, remote -v, rev-parse --git-dir, and config --null --get core.fsmonitor

   An immediate follow-up snapshot found:

   • 31 live git.exe processes
   • 19 older than 5 seconds
   • oldest process: 118.59 seconds
   • fresh Git-for-Windows wrapper/child pairs directly rooted under the packaged codex.exe app-server
   • many older children whose recorded parent had already exited

   The app-server handle count increased from 490 to 621 during the 45.78-second sample and was 677 at the follow-up snapshot. This short observation is not enough by itself to claim a persistent handle leak, but it confirms substantial process/handle churn.

   One tracked workspace still contains an empty/invalid .git directory, so that remains a plausible amplifier. However, the product behavior is unchanged: the app-server continues launching periodic Git metadata batches, and timed-out wrapped children can outlive their parent on Windows.

   Conclusion

   26.715.7063.0 appears to mitigate the synchronous HID freeze, but it does not include an effective Windows Git process-tree cleanup or invalid-repository backoff fix. The focused Windows cleanup implementation remains available here:

   areslp@b8d7f3c

   PR #30235 has now received a maintainer approval, but it remains open and Unix-only. If maintainers want the Windows equivalent submitted, an invitation would let me open the focused PR immediately.
8. areslp commented on Jul 24, 2026

   

   areslp

   on Jul 24, 2026 – with ChatGPT Codex Connector

   More actions

   Follow-up after updating the same Windows host to the current Microsoft Store package.

   Current build

   • Package: OpenAI.Codex_26.721.3996.0_x64__2p2nqsd0c76g0
   • Windows 11 x64
   • The original empty marker directory D:\work\.git still exists and still has zero children.

   Idle/periodic path is substantially improved

   A 55.82-second read-only external sample while the app was naturally idle observed:

   • 4 distinct git.exe PIDs, peak concurrent count 2
   • 5 distinct taskkill.exe PIDs, peak concurrent count 2
   • zero residual Git/taskkill processes
   • main window responsive in 152/152 checks

   This is dramatically better than the sustained process storms reproduced in earlier packages.

   Session switching still causes visible stutter and a process burst

   The user still perceives a short but obvious freeze when switching desktop sessions/threads. I ran a second 60.82-second, 250 ms external process sample while reproducing session switching:

   • 10 distinct git.exe PIDs
   • 11 distinct taskkill.exe PIDs
   • peak concurrent Git count: 2
   • peak concurrent taskkill count: 3
   • the activity was concentrated in a roughly 12-second window, from 23:17:48.859 through 23:18:00.567 local time
   • zero residual Git/taskkill processes at the end
   • main window remained Responding=True in 172/172 checks
   • main-window handle count remained flat at 258

   The important distinction is that this no longer looks like the old long-lived process accumulation, but it is also not fully fixed. Session switching still coincides with a short burst of Git and cleanup processes, and the user-visible stall is shorter than Windows' coarse Responding/hang detection.

   The current desktop log files for this process were still zero bytes/unflushed during the capture, so I cannot yet prove from logs whether this burst is specifically thread/list, rollout metadata repair, or Git enrichment. The external timing correlation is reproducible, but I do not want to overstate the exact internal call path without flushed logs or ETW.

   Current conclusion

   The 3996 package appears to have strongly improved the idle/periodic Git storm on this machine, but the latency-sensitive session-switch path still stutters and still launches a concentrated Git/taskkill burst. Please keep session switching and active-agent work as separate acceptance paths; a clean idle sample does not cover either one.
9. areslp commented on Jul 26, 2026

   

   areslp

   on Jul 26, 2026 – with ChatGPT Codex Connector

   More actions

   Follow-up after several additional Store updates: the same Windows host is now running OpenAI.Codex_26.721.4979.0_x64, and the app feels materially slower again, particularly when switching sessions.

   Git/process-tree control

   A 60.70-second, 250 ms read-only sample observed:

   • root window responsive in 184/184 checks
   • 1 distinct git.exe, peak 1
   • 2 distinct taskkill.exe, peak 2
   • zero residual Git/taskkill processes

   Therefore the old sustained idle Git process storm was not active in this window. The public Git timeout implementation still lacks Windows process-tree cleanup, so this does not close the Git bug; it only narrows the current 4979 slowdown to a different active path.

   Renderer/app-server amplification

   The same live sample recorded:

   • aggregate ChatGPT/Electron working-set peak: about 2,087.5 MiB
   • packaged app-server: about 650.1 MiB working set / 1,152.4 MiB private memory
   • three heavy renderers at roughly 682.6, 480.1, and 349.4 MiB working set

   The flushed 4979 desktop log contained:

   • 420 thread/list responses
   • average 35.1 ms, p95 80 ms, maximum 457 ms
   • bursts up to 16 thread/list responses in one second

   Individual responses are usually short, but the redundant bursts add foreground work during navigation/session switching.

   Local config is still being overridden

   Although concurrent_reasoning_summaries = false remains configured, the renderer resolved the feature to true 413 times and to false zero times. The same log had 15,123 reasoning-related rows and 512 ResizeObserver-loop errors. Reasoning completion rows were replicated about 2.92 times per unique item across primary and hidden overlay/dictation renderers.

   The full current-build evidence is posted here:
   #33996 (comment)

   Current conclusion

   There are at least two separate Windows acceptance paths:

   1. Git/taskkill lifecycle and cleanup during active work.
   2. Desktop renderer/session-navigation performance.

   4979 looked clean for idle Git in this sample, but the second path has regressed: session switching still stutters, remote reasoning-summary enablement overrides the local config, renderer work is duplicated, and the long-lived process footprint exceeds 2 GiB.

   Please do not treat a clean idle Git sample or Responding=True as evidence that the Windows desktop performance issue is resolved.
10. v2-share commented on Aug 5, 2026

    

    v2-share

    on Aug 5, 2026 – with ChatGPT Codex Connector

    More actions

    Additional evidence from current Windows build

    I am adding this to the existing issue because the symptom matches the Windows chat-switching/UI stutter described here. This is not a new issue.

    Environment and symptom

    • Windows desktop app, Microsoft Store build 26.730.8199.0.
    • After a clean launch, mouse/input lag is most noticeable shortly after opening the app and can recur when switching conversations. The behavior is intermittent and may clear after a short period.

    Observed timings from the existing local trace

    • thread/resume: 1,177 ms and 1,551 ms, with additional calls around 1.0-1.4 s.
    • plugin/list: 1,601 ms, with additional calls at 2,385 ms, 2,786 ms, and 3,666 ms.
    • config/read: approximately 690-1,102 ms.
    • plugin/installed: approximately 733-1,102 ms.
    • main_thread_jank_snapshot: 4 occurrences.

    Interpretation

    These timings coincide with conversation restoration/history handling and plugin/config loading during the UI stall. They suggest UI/main-thread contention around thread switching, but do not by themselves prove a single root cause.

    Distinction from the older WMI reports

    On the same current build, the clean-start trace did not show electron-sampler snapshot failures, WMI Event 5858, a PowerShell/WMI snapshot storm, or taskkill.exe/conhost.exe/git.exe process storms. The current chat-switching lag therefore appears to be a separate or later Windows UI performance path rather than the older WMI sampler issue.

    Related reports that seem relevant: #29187 and #29590.