Codex App startup gets heavy with stale workspaces and old state

Codex
, ,
1

I wanted to share some constructive feedback about Codex App for Windows as someone who has been using Codex quite a bit and genuinely appreciates the direction of the product.

On my machine, startup seems to eagerly probe Git and workspace state across historical projects, including stale paths that no longer exist. This leads to repeated ENOENT / origin-resolution errors, multiple git.exe processes, and startup behavior that feels noticeably heavier than Codex CLI in the same environment.

My main concern is that startup cost may gradually grow over time as historical projects, stale workspace paths, and old thread/rollout state accumulate.

I’m sharing this in good faith because I think the app is already very promising, and this feels like an area where some cleanup around startup behavior could noticeably improve the overall experience. I have logs and additional evidence available if useful.

Product Area

  • Codex App for Windows
  • Version observed in logs: OpenAI.Codex_26.311.2262.0_x64__2p2nqsd0c76g0

Summary

On startup, Codex App appears to eagerly initialize multiple subsystems at once, including:

  • remote connection discovery from %USERPROFILE%\.ssh\config
  • thread/list
  • repeated config/read
  • model/list
  • plugin/list
  • skills/list
  • WSL discovery
  • git repo watcher
  • git-origins and git-origin-and-roots scans across historical workspaces

This becomes noticeably heavy on Windows when the user has many historical projects, especially stale paths that no longer exist.

In my case, the startup path repeatedly probes missing workspaces and spawns multiple git.exe processes, while Codex CLI stays much lighter under the same environment.

Repro Characteristics

  • Windows environment
  • Codex App startup after accumulating many historical projects/workspaces
  • .codex/config.toml currently contains 45 project entries
  • several historical paths are stale / no longer exist

What I Observed

1. App startup chain is broad and eager

From startup logs:

  • App launches and mounts UI quickly
  • then starts app-server over stdio
  • then loads account / thread / config / models / plugins / skills
  • then starts git watcher and workspace origin resolution

Observed log events included:

  • thread/list
  • config/read
  • model/list
  • plugin/list
  • skills/list
  • Starting git repo watcher
  • remote-connections/discovery_started
  • wsl eligible distro list

2. Stale workspace paths are repeatedly scanned

The app attempts git-origins / git-origin-and-roots resolution on missing paths and logs ENOENT.

Examples from this session:

  • E:\<redacted-root-A>\<redacted-workspace-A>
  • E:\Workspace\<redacted-workspace-B>
  • F:\<redacted-root-B>\<redacted-workspace-C>
  • E:\Workspace\<redacted-project-D>
  • K:\<redacted-project-E>

Observed log signatures:

  • [git-origins] failed to list worktrees
  • [git-origin-and-roots] Failed to resolve origin for workspace
  • ENOENT: path does not exist

3. Git probing happens even in non-repo contexts

Observed warning:

  • git rev-parse --abbrev-ref HEAD
  • cwd=C:/Users/<redacted-user>
  • exitCode=128

This suggests the startup path is probing contexts that are not valid Git repos.

4. Historical state restoration may add additional startup cost

Historical .codex logs also include signals that old rollout/thread state may be restored or repaired during app activity, including:

  • repeated Resumed rollout successfully from ...
  • repeated model cache evaluation / cache miss / cache version mismatch
  • state db discrepancy during read_repair_rollout_path

I cannot confirm from these logs alone how much of this is strictly on the critical startup path, but it appears plausible that historical state restoration or repair may compound startup cost when combined with workspace scanning.

Why This Feels Expensive

The current behavior appears to do a lot before the app settles:

  • scan remote connection metadata
  • initialize app-server
  • restore UI/session state
  • resolve workspace origins
  • probe Git metadata
  • load model/plugin/skills metadata

When stale paths exist, the startup work includes predictable failures that still consume time and process churn.

Possible Areas Worth Looking Into

I may be off on the exact implementation details, but a few things seem worth investigating:

  • how much historical workspace probing happens during startup, especially for stale or missing paths
  • whether repeated failures on the same invalid paths are being retried more often than necessary
  • whether older workspaces, threads, or rollout state could be restored more lightly at startup
  • whether some parts of Git/workspace resolution could be deferred until a workspace is actually active
  • whether startup-critical work and historical/background restoration work could be separated more clearly

Why I Am Filing This

Codex CLI is noticeably lighter in the same environment.

The app clearly provides more UI and context features, but right now the startup path seems to pay for a lot of historical artifacts at once. This becomes more visible as old projects and old threads accumulate over time.

Useful Evidence To Attach

  • desktop logs under:
    • %LOCALAPPDATA%\Packages\OpenAI.Codex_...\LocalCache\Local\Codex\Logs\YYYY\MM\DD\
  • relevant startup logs:
    • codex-desktop-7a4f30b7-...-t0-i1-052604-0.log
    • codex-desktop-7a4f30b7-...-t2-i1-052610-0.log
  • current project count:
    • .codex/config.toml project entries = 45
  • additional evidence available if useful:
    • approximate cold-start vs warm-start timings
    • count of stale/missing paths observed in logs
    • process snapshot showing multiple git.exe instances during startup