[Windows] First launch after update takes 6+ minutes due to extremely slow runtime materialization

On Windows, the first launch of ChatGPT Desktop after an application update can take approximately 6–10 minutes before the UI becomes usable.

Subsequent launches are normal and take only a few seconds.

I performed a local forensic investigation and found that the long startup corresponds closely to the materialization of approximately 4,128 bundled runtime files (~639.9 MB) into "%LOCALAPPDATA%\OpenAI\Codex".

This appears similar to other reports of slow runtime extraction/materialization after updates, but I have not yet determined whether the delay is caused primarily by the application's own file-processing logic, MSIX behavior, Defender, or an interaction between them.

Environment

• OS: Windows
• Distribution: Microsoft Store / MSIX
• Package: "OpenAI.Codex"
• Package version observed during investigation: "26.911.7940.0"
• Electron/Chromium: "153.0.8010.36"
• Package installation volume: "D:\WindowsApps"
• User runtime/cache: "%LOCALAPPDATA%\OpenAI\Codex"
• Storage: KIOXIA KBG50ZNV1T02 NVMe SSD
• Filesystem: NTFS
• Allocation unit: 4 KB
• No third-party antivirus/EDR was found

Reproduction
The issue consistently occurs on the first launch after an application update.

Typical sequence:

1. ChatGPT Desktop updates through Microsoft Store/MSIX.
2. Launch ChatGPT for the first time after the update.
3. "ChatGPT.exe" starts, but the UI is unavailable for several minutes.
4. Thousands of files appear/materialize under:
   • "%LOCALAPPDATA%\OpenAI\Codex\bin"
   • "%LOCALAPPDATA%\OpenAI\Codex\runtimes"
5. After this process completes, the UI becomes usable.
6. Close ChatGPT.
7. Launch it again.
8. The subsequent launch takes only a few seconds.

Detailed startup timeline
A representative startup was measured on 2026-09-18.

Approximate timeline:
07:35:54 ChatGPT process/startup begins
07:35:54–07:38:10 Large runtime materialization activity
07:38:10 Main materialization activity has completed
07:38:27 ChatGPT UI becomes usable

The measured total startup time from process start to usable UI was approximately:
6 minutes 20 seconds

Approximately:
4 minutes 46 seconds
of that period was associated with the observed bundled-runtime materialization activity.

A subsequent launch:
07:55:46 ChatGPT starts
07:55:52 ChatGPT usable

took approximately:
6 seconds

This large difference between the first post-update launch and subsequent launches is highly reproducible.

Runtime materialization details

During the slow first launch, approximately:
4,128 files
639.9 MB
were created/materialized under:
%LOCALAPPDATA%\OpenAI\Codex\

including files under:
bin
runtimes\

Examples include:
codex.exe ~292.92 MB
code-mode-host ~69.14 MB
node.exe ~89 MB
node_modules ~4,123 files

The files in the user directory were byte-for-byte identical to the corresponding files in the MSIX package.

SHA-256 comparisons matched.

This suggests that the operation is not downloading a different runtime from the network; it is materializing/copying the bundled runtime into the user directory.

Network observation

During the critical materialization window:

07:35:54–07:38:10

no proxy/network connections were observed.

Therefore, the multi-minute delay does not appear to be caused by downloading these runtime files.

Disk / filesystem investigation

I compared the C: and D: volumes because the ChatGPT package was installed under "D:\WindowsApps".

Both volumes are partitions on the same physical SSD:

Disk 0
KIOXIA KBG50ZNV1T02 NVMe SSD

Both use:

NTFS
4 KB allocation unit

Approximate volume sizes:

C: ~249.8 GB, ~118.9 GB free
D: ~703.1 GB, ~252.4 GB free

EFS

The ChatGPT MSIX package on D: is EFS-encrypted.

A sample of WindowsApps packages on C: showed:

162 packages sampled
0 EFS-encrypted

On D:

7 packages sampled
7 EFS-encrypted

However, controlled file-copy benchmarks indicate that EFS cannot explain the multi-minute startup delay.

Controlled 4,123-file copy benchmark

Approximately 4,123 files were copied under controlled conditions.

Results:

D: EFS package → C: temporary directory
5.55 seconds
~743 files/s

D: EFS package → D: temporary directory
5.52 seconds
~746 files/s

C: non-EFS source → D: temporary directory
3.66 seconds
~1,126 files/s

C: non-EFS source → C: temporary directory
3.42 seconds
~1,138 files/s

Thus, the EFS source adds only roughly 2 seconds in this benchmark.

That is negligible compared with the approximately 286 seconds of observed materialization activity.

This also suggests that simply moving the application from D: to C: is unlikely to eliminate the multi-minute delay.

Cold vs. warm file access

Additional testing showed that newly introduced/sufficiently cold small files can be much slower to access than already-warmed files.

However, the extremely slow behavior observed during the ChatGPT post-update startup was substantially worse than the normal cold-read behavior.

Once the files had been processed/materialized, subsequent launches were thousands of files per second / only a few seconds overall.

This strongly suggests that the problem is specific to the post-update first-touch/materialization path rather than a persistent storage performance problem.

Filesystem filter drivers

The same system-level filesystem filters were observed on both volumes, including:

WdFilter Windows Defender
FileCrypt BitLocker
ahflt Microsoft PC Manager
BEDaisy BattlEye

No third-party antivirus/EDR was identified.

Windows Defender ("MsMpEng.exe") was active around the relevant period.

However, I have not yet established that Defender accounts for the majority of the approximately 286 seconds of materialization time.

I therefore do not want to claim that Defender is the root cause without a ProcMon trace.

What appears to be happening

The observed sequence appears to be approximately:

MSIX update
↓
First launch
↓
Bundled runtime is materialized into
%LOCALAPPDATA%\OpenAI\Codex
↓
~4,128 files / ~640 MB
↓
Very slow processing of many individual files
↓
ChatGPT UI becomes usable
↓
Subsequent launches are fast

The fact that:

• the files already exist inside the MSIX package,
• the copied files are byte-for-byte identical,
• there is no observed network activity,
• the storage device performs normally in controlled tests,
• EFS adds only a few seconds in the benchmark,
• and subsequent launches take ~6 seconds,

makes the post-update runtime materialization path the strongest correlation I have found so far.

Defender hypothesis

Defender may contribute to the slowdown because thousands of newly materialized executable/script/module files are being touched for the first time.

However, current evidence does not establish Defender as the primary bottleneck.

I have not disabled Defender or added exclusions.

A future Process Monitor capture can determine whether:

ChatGPT.exe file operations

are being delayed in correlation with:

MsMpEng.exe / WdFilter

or whether ChatGPT itself is spending most of the time performing serialized file operations.

Previous update-staging observations

There is also evidence that the MSIX update/staging process itself can take several minutes before the first launch.

Observed examples include approximately:

2026-09-17 448.8 seconds
2026-09-16 225.5 seconds
2026-09-15 272.8 seconds

These appear to be separate from the measured first-launch materialization delay.

Therefore, the user's perceived total "update → usable ChatGPT" time can be even longer than the approximately 6-minute first-launch measurement.

Other observations

No ChatGPT application crash or Windows Error Reporting event was found for the slow launch.

No evidence of:

• GPU initialization failure
• memory pressure
• SSD saturation
• database migration taking several minutes
• update process deadlock

was found during the investigation.

The system otherwise appears healthy.

Expected behavior

After an application update, ChatGPT Desktop should become usable within seconds or should avoid blocking the first UI launch for several minutes while synchronously materializing thousands of bundled runtime files.

Actual behavior

The first launch after an update can take approximately:

6–10+ minutes

with approximately:

4,128 files
~639.9 MB

being materialized before the application becomes usable.

Subsequent launches take only a few seconds.

Requested investigation

Could the Windows/MSIX startup path be investigated to determine whether the bundled runtime can be:

• materialized asynchronously,
• reused directly from the MSIX package where possible,
• extracted during the update rather than blocking the first launch,
• or otherwise optimized to avoid processing thousands of individual files synchronously?

I can provide a Process Monitor (".PML") capture from the next update to correlate:

• "ChatGPT.exe"
• "MsMpEng.exe"
• "CreateFile"
• "ReadFile"
• "WriteFile"
• file-operation duration
• and the runtime materialization timeline.

The main question is why approximately 4,128 already-bundled files require several minutes to become usable after every update.

Start with the Windows/MSIX startup path and reproduce the first post-update launch while capturing ChatGPT.exe, MsMpEng.exe, WdFilter, and file-operation timings in Process Monitor. Done means identifying whether application file processing or Defender-related activity causes the delay and determining whether startup can avoid blocking on runtime materialization.