We examined where ChatGPT and Codex store their files, placed the app itself and its main data on drive D, and left about 3.78GB of active runtimes and other files on drive C. The files to consider fall into three groups: the app, stored data, and runtimes.
Three main groups of files
“Move everything related to ChatGPT to drive D” turned out to cover too much. The files that run the app are separate from those that store conversations and settings. The CLI, Python, Node, and other components called by the app were also deployed in different locations.
| Component | Location in this case | What we did |
|---|---|---|
| Codex home | D:\CodexHome | We pointed the official environment variable directly at the existing data. |
| The app itself and its main app data | WindowsApps and WpSystem on drive D | We used Windows’ built-in app move feature. |
| CLI, shared runtimes, VS Code extension, and other components | Drive C | We kept their existing, active locations. |
OpenAI’s environment variable specification states that CODEX_HOME sets the root for configuration, authentication, logs, sessions, skills, and related state. The directory must already exist. This setting does not move the app itself, Windows AppData, and all associated runtimes together.
Preserving Codex’s local sessions is also different from exporting an entire ChatGPT account’s cloud conversation history. We do not treat this backup as a complete export of all ChatGPT data.
What was already on drive D, and what changed
When the investigation began, the actual Codex home data was already on drive D. On drive C, %USERPROFILE%\.codex was a junction pointing to CodexHome on drive D. In other words, this operation did not initially transfer roughly 65GB of home data from drive C to drive D; the data was already on drive D.
A junction makes one folder an entry point to another folder. Microsoft documents how it can point to another local volume on the same computer. Seeing files through an entry point on drive C does not necessarily mean a second copy is stored there. Microsoft’s explanation of junctions
Default home on drive C
↓ Junction
CodexHome on drive D
Explicit CODEX_HOME setting
↓ Direct reference
CodexHome on drive D
This distinction also mattered when investigating the browser problem. The built-in browser and Chrome integration recovered after we specified the home’s actual path, fully quit the app, and restarted it. However, we did not measure the effects of the path setting and restart separately. Our browser recovery case describes the before-and-after state and the checks we used.
Backing up about 68.6GB while the apps were stopped
Before changing how the app starts, we made a backup with ChatGPT, Codex, and the related Codex components in the IDE stopped. We copied the Codex home, the actual app package storage area, and the OpenAI folder in the ordinary Local AppData location. We kept the backup on drive C, rather than on the destination drive.
| Component | Logical size | Regular files |
|---|---|---|
| Codex home | About 64.82GB | 429,989 |
| App package storage area | About 2.60GB | 12,906 |
| OpenAI in Local AppData | About 1.17GB | 2,384 |
| Total | 68,587,172,965 bytes, about 68.6GB | 445,279 |
The table shows the logical size of the backup made on this computer. GB is calculated as one billion bytes. The roughly 68.6GB is the size of the backup retained on drive C, not the amount of space freed on drive C.
- 445,279 files
- We compared file counts, sizes, and modification times.
- 144 important files
- We also compared SHA256 hashes for settings, databases, authentication files, and other important files.
- One link excluded
- We did not follow a junction inside the home, and recorded why it was excluded.
Only the user and SYSTEM can access the backup location. The backup itself is not attached to this article because it contains authentication files and private conversations.
When the folder was missing from ordinary AppData
The first attempt stopped because it assumed a Codex folder existed at the ordinary AppData path. The corresponding data was actually inside the app’s storage area, so we corrected the list of sources and tried again. We did not conclude that data had disappeared merely because it was absent from the default location.
Testing CODEX_HOME, then checking normal startup
Because the home was already on drive D, we first tested a single launch with CODEX_HOME=D:\CodexHome set. We kept the same app version, fully quit it, and started a new instance.
- Test launch
We pointed directly to drive D and checked the locations referenced by the shell and browser-control configuration. - Check basic operations
We checked reading and clicking in the built-in browser and Chrome, along with saved items. - Apply to normal startup
After approval, we set the user environment variable and checked a new app instance launched from the taskbar.
The only change was to the user-scoped CODEX_HOME variable. We did not change machine-wide environment variables or PATH. Windows environment variables have process, user, and machine scopes, so we checked the app launched normally rather than stopping after seeing the value in one shell. Microsoft’s explanation of environment variables
Read-only commands for checking your storage location
The following PowerShell only reads values. The first line shows the value used by that shell; the second and third show the settings stored in Windows; the last shows the entry point for the default home. A value may be empty, so a blank result alone does not mean data has been lost.
$env:CODEX_HOME
[Environment]::GetEnvironmentVariable('CODEX_HOME', 'User')
[Environment]::GetEnvironmentVariable('CODEX_HOME', 'Machine')
Get-Item -LiteralPath (Join-Path $env:USERPROFILE '.codex') -Force |
Select-Object FullName, Attributes, LinkType, TargetNo move or delete commands are included here. This test started with data already on drive D, which is different from simply pointing the setting at an empty folder. Before applying the approach to another computer, decide what must be copied, which apps must be stopped, and where you would restore the data.
Moving the app with Windows’ built-in feature
After checking the home setting and browser recovery, the operator selected “Move” for ChatGPT in Windows’ app list and moved it to drive D. Its destinations were Windows-managed WindowsApps and WpSystem. Microsoft’s explanation of package storage locations
The install path reported by Windows or a process
The app itself and its main app data
Do not delete the entry point on drive C on the assumption that it is an unnecessary duplicate.
We checked the successful move event, the valid signature of the executable on drive D (OpenAI OpCo), and the link on drive C. For app data, the corresponding folders also had matching device IDs and file IDs.
A displayed location alone cannot establish either a successful move or duplicate storage. We checked the actual locations, their targets, and basic operations together. We did not change Windows-managed entry points or permissions.
Why about 3.78GB stayed on drive C
Even after the main components were moved, active data remained on drive C. The table below summarizes known related storage areas, without double-counting entry points to drive D.
| Files kept on drive C | Logical size | Reason |
|---|---|---|
| App-managed CLI and integration runtimes | About 1.17GB | The app was actively using these files from drive C. |
| Shared runtimes | About 1.82GB | These were the current locations for Python, Node, Git, libraries, and related components. |
| ChatGPT extension for VS Code | About 760MB | This installation is separate from the desktop app move. |
| Some Windows-managed files and related temporary files | About 31MB | Windows-managed storage and related files present during the investigation. |
| Total | About 3.78GB | Excludes the pre-migration backup. |
This total is the logical size of known folders. It is not an exhaustive count of update caches, restore points, or everything saved by every browser and editor across drive C.
The runtimes left on drive C can work without matching copies on drive D because the app is using the current files on drive C. Deleting them on the assumption that they have been migrated could break the CLI or browser control. The final setup in this case uses both drives C and D.
We also examined the official CODEX_INSTALL_DIR variable, but it changes the installation location for the standalone CLI installer. It does not relocate all app-managed CLI components and shared runtimes. Installing an additional CLI on drive D does not establish that the existing files on drive C are no longer needed.
We also inspected the update process for this version without changing it, and tested replacement using small dummy folders. In one configuration, making the folder being updated a link to drive D caused the link to be moved aside as the old version, while a new regular folder was created on drive C. This test checked file replacement only; it was not a migration test of the real app.
We chose not to add unofficial locations and extra post-update checks merely to move roughly 3GB of runtimes. We weighed the benefit of moving the app and main data to drive D against the remaining space used on drive C, and kept the components that were working normally.
What we checked after the migration
We did not stop at “the app starts.” We compared the current saved values against the backup. The checked items matched, including 2 pinned chats, 18 pinned projects, 63 local projects, 43 project-order entries, and 58 chat-to-project assignments. We compared the complete values of the selected items, not just their counts.
For history and related files, all corresponding files from the backup were present and readable: 459 files in sessions, 39 in archived_sessions, 4 in attachments, and 3 in automations. There were 0 missing files and 0 read errors. This was a file-presence check; it does not mean every conversation body or the full contents of every database were hashed again.
The CLI login-status check completed successfully. The built-in browser could read a public page, click a link, and go back. We also checked reading and navigation in a dedicated Chrome test tab, then closed that tab. We did not collect content from existing private tabs for the article.
We verified an ordinary app restart, but have not checked continuity after restarting the PC itself or after a future app update. Those two checks were deferred until a convenient time for the user. We did not add another restart just to complete this article.
The configuration we kept
We considered the migration complete within this scope: directly specifying the home’s actual path on drive D, placing the app and its main data on drive D, and retaining the runtimes on drive C. The roughly 68.6GB pre-migration backup remains on drive C; the user will decide when to delete it separately.
The important part of moving to another drive was understanding what is stored where, which app uses it, and what is retained for recovery, rather than reducing drive C usage to zero. In particular, when registering a destination as a Windows app storage location for the first time, the shutdown plan needs to cover virtual disks and active projects on that same drive.
Order for doing the same migration
- Divide the targets into three groups, the Codex home, the app itself and its main app data, and runtimes such as the CLI, and confirm where each one currently lives.
- Stop not only ChatGPT and Codex, but also apps using the destination drive (such as Docker’s virtual disk) and any active projects.
- With everything stopped, take a backup, compare file counts and sizes, and also compare hashes for important files such as settings and authentication. Keep the backup on a drive other than the destination.
- Test CODEX_HOME with a single launch first, confirm basic operations, and only then set it as a user environment variable.
- Move the app itself with Windows’ “Move” feature. Do not delete the entry point (junction) left on drive C.
- Do not delete the runtimes remaining on drive C while the app is using them.
- Do not stop at “the app launched.” Check saved items, history files, and browser operations. Check again after a PC restart and after an app update, and only then decide whether to delete the backup.
Frequently asked questions
Will setting CODEX_HOME to drive D move everything related to ChatGPT there?
No. It specifies the root used to store Codex state. On this computer, the app itself was moved separately, while the CLI, shared runtimes, and VS Code extension stayed on drive C.
Can I delete the .codex or app folders that appear on drive C?
In this case, drive C contains entry points to drive D. Even if they appear to occupy space, they are not necessarily separate copies. Deleting an entry point breaks the reference. We also kept the management links created by Windows unchanged.
Can I delete the pre-migration backup immediately?
We kept it on this computer. The plan is to continue the necessary work with the new layout, check after a PC restart or update when appropriate, and let the user decide when to delete the backup.
Do I need to move the app itself just to fix the browser?
In this case, the browser recovered before the app itself was moved to drive D. There is no basis here for recommending an app move as a required browser-repair step.
Scope of this record and drive notation
In this article, the drive containing Windows is called drive C, and the destination is called drive D. For readability, example paths also consistently use drive D.
This article records a migration performed on the operator’s Windows computer on October 20, 2026, and the file, log, and browser checks performed by Codex. It covers the desktop app package that provides ChatGPT and Codex, OpenAI.Codex 26.1013.4894.0. The operator performed the built-in Windows app move.
