Windows Desktop exec silently uses MSIX-virtualized AppData instead of the real user profile

What version of the Codex App are you using (From “About Codex” dialog)?

Codex Desktop MSIX 26.825.6671.0

What platform is your computer?

Windows 11 Pro, version 10.0.26200, build 26200, x64

What issue are you seeing?

In a Windows-native Codex Desktop task, commands executed by the agent silently see a package-private MSIX copy of %APPDATA% instead of the user's real profile data.

This happens with the Codex sandbox fully disabled:

approval_policy = "never"
sandbox_mode = "danger-full-access"

For example, an agent command opening this textual path:

C:\Users\<user>\AppData\Roaming\netlify\Config\config.json

actually opens this file according to GetFinalPathNameByHandle:

\\?\C:\Users\<user>\AppData\Local\Packages\OpenAI.Codex_2p2nqsd0c76g0\LocalCache\Roaming\netlify\Config\config.json

The two files are different:

Real user profile file SHA-256:
073a2440c1f66fa4848f4490b37da409dca5fb76b82202ea0ae07e27b94059c7

Package-private LocalCache file SHA-256:
81acac35e22045db93ec5c512015623782c8fcf04b5f19b4a894c6e9d2867c54

A normal unpackaged Windows terminal sees the real file. Codex agent exec in Windows-native mode sees the package-private file. This is not an environment-variable mismatch: %APPDATA% contains the expected textual path in both processes. The redirection occurs when the path is opened.

The package-private profile already contains shadows for multiple unrelated programs, not just the CLI used in this example. This can silently split configuration, authentication state, caches, and application data between normal user processes and Codex agent commands.

The Codex exec process reported:

GetCurrentPackageFullName: no package identity
IsAppContainer: false
Token virtualization enabled: false

Despite that, the opened path was redirected into the Codex package's LocalCache.

What steps can reproduce the bug?

1. Install Codex Desktop from the Microsoft Store/MSIX package.
2. Select Windows native as the agent environment.
3. Configure sandbox_mode = "danger-full-access" and start a new task.
4. From a normal unpackaged Windows terminal, create an application config under %APPDATA% or use an existing CLI that stores authentication/configuration there.
5. Run that CLI from a Codex agent command, causing it to access the same %APPDATA% path.
6. Compare the file seen by the normal terminal and the file seen by Codex agent exec.
7. For definitive evidence, open the file in the Codex exec process and call GetFinalPathNameByHandle on its handle.
8. Observe that the Codex command opens %LOCALAPPDATA%\Packages\OpenAI.Codex_2p2nqsd0c76g0\LocalCache\Roaming\... while the normal terminal opens the actual %APPDATA%\... file.

A deterministic variant is:

1. From an unpackaged terminal, write a marker file under %APPDATA%\codex-msix-repro\probe.txt.
2. From Codex agent exec, write a different value to the same textual path.
3. Compare the file from the unpackaged terminal and Codex exec.
4. Inspect the final opened path from Codex exec.

What is the expected behavior?

In Windows-native mode with danger-full-access, agent commands should operate on the same user profile and application configuration as commands launched from the user's normal Windows terminal.

At minimum, Codex must not silently present a second private %APPDATA% tree while reporting the normal user path in environment variables. If isolation is intentional, it should be explicit, documented, and controllable.

Actual behavior and impact

• Existing CLI authentication appears to be missing inside Codex.
• Logging in from Codex can create a second credential/configuration state that normal terminals do not see.
• Programs can read and write stale or divergent settings without any visible path difference.
• Disabling the Codex sandbox does not fix the behavior because this is MSIX filesystem virtualization, not the Codex sandbox.
• The integrated terminal can behave differently from agent exec even within the same Codex Desktop window.

This makes Windows-native agent execution unreliable for any tool using %APPDATA% or %LOCALAPPDATA%.

Additional information

Microsoft documents that packaged desktop apps can redirect writes under AppData into a per-user, per-package location. Package authors can disable filesystem write virtualization in the package manifest. Codex Desktop should either disable this virtualization for agent execution or spawn agent commands through an unpackaged broker that sees the real user profile.

Related but distinct issues:

• #40328 — an explicit Git Bash exec_command.shell can be discarded/fall back to another shell. This blocks using Git Bash as a reliable workaround, but it is not the AppData redirection itself.
• #16579 — request to configure the default Windows session shell. This also does not address MSIX profile virtualization.

The issue was reproduced in a fresh Codex task. No credential contents or tokens are included in this report.

Start with the Windows-native agent exec path and reproduce the mismatch using the deterministic %APPDATA% probe. Inspect the opened handle with GetFinalPathNameByHandle and review the MSIX package manifest or unpackaged broker behavior. Done means danger-full-access commands see the same user-profile files as a normal terminal, or any isolation is explicit and documented.