Windows: first Create click after restarting Codex deletes hatch-pet skill and fails to restore it

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

26.901.5280.0

What subscription do you have?

ChatGPT Plus

What platform is your computer?

Microsoft Windows NT 10.0.26200.0 x64

What issue are you seeing?

After restarting the Codex desktop app on Windows, the first click on the pet Create button deletes the existing hatch-pet skill.

Codex then appears to try to restore/copy the bundled hatch-pet skill from the MSIX installation under C:\Program Files\WindowsApps\..., but the copy fails.

The resulting error is equivalent to:

The specified file could not be encrypted.

On my localized Windows installation, the error is:

无法加密指定的文件

After this failure, the previously existing hatch-pet skill is gone, so the pet feature is left without a working skill.

I investigated the bundled files and found that the hatch-pet directory is present and complete (27 files). The issue does not appear to be caused by missing or corrupt skill files.

The source files inside the MSIX/WindowsApps package appear to be application-protected. cipher /c reports them as encrypted/application-protected.

Copy behavior for the exact same files differs depending on the copy method:

• PowerShell Copy-Item: fails with The specified file could not be encrypted.
• ReadAllBytes() + WriteAllBytes(): succeeds
• robocopy /E /COPY:DAT /DCOPY:DAT: succeeds for all 27/27 files

The destination .codex directory is not EFS-encrypted and the filesystem is NTFS.

This suggests the failure may be caused by the file-copy implementation attempting to preserve MSIX/Application Protection or encryption metadata when copying the bundled skill into a normal user-writable directory.

What steps can reproduce the bug?

1. Start Codex and make sure the hatch-pet skill currently exists and works.
2. Restart the Codex desktop app.
3. Open the pet UI.
4. Click Create for the first time after the restart.
5. Observe that the existing hatch-pet skill is deleted.
6. Codex then fails to restore/copy the bundled skill.
7. The pet feature is left without a working hatch-pet skill.

The bundled skill is located under a path similar to:

C:\Program Files\WindowsApps\OpenAI.Codex_<version>_x64__2p2nqsd0c76g0\app\resources\skills\skills\.curated\hatch-pet

The underlying file-copy failure can also be reproduced outside Codex.

For example, attempting to copy the bundled skill with PowerShell:

Copy-Item "<WindowsApps hatch-pet source>" "<normal user-writable destination>" -Recurse

fails with:

The specified file could not be encrypted.

However, copying the same files with:

robocopy "<source>" "<destination>" /E /COPY:DAT /DCOPY:DAT

succeeds for all files.

What is the expected behavior?

Clicking Create should not delete an existing working hatch-pet skill unless the replacement has already been copied and verified successfully.

If the bundled skill needs to be restored or updated, Codex should first copy it to a temporary location, verify that the copy completed successfully, and only then replace the existing skill.

If the replacement copy fails, the existing working skill should remain untouched.

The Windows copy operation should also avoid inheriting MSIX/Application Protection or encryption metadata that cannot be applied to the normal destination directory.

Additional information

Additional diagnostic findings:

• Windows 11 Pro 25H2
• OS build observed during debugging: 26200.9168
• NTFS filesystem
• The destination .codex directory is not EFS-encrypted.
• The bundled hatch-pet directory contains 27 files.
• The bundled files are readable and their contents are valid.
• cipher /c reports the source files with E and an application-protected compatibility level.
• PowerShell Copy-Item fails.
• ReadAllBytes() + WriteAllBytes() succeeds.
• robocopy /E /COPY:DAT /DCOPY:DAT succeeds for all 27/27 files.

This appears to involve two related issues:

1. The Windows copy path used for bundled skills may incorrectly try to preserve MSIX/Application Protection or encryption metadata.
2. The replacement flow is destructive: the existing skill is deleted before the replacement has been successfully staged.

A safer replacement flow would be:

bundled skill -> temporary directory -> verify -> atomic replace

If staging fails, the existing hatch-pet skill should remain untouched.

Trace the Windows skill restore/copy path triggered by the pet Create action and inspect the order in which the existing hatch-pet directory is deleted and the bundled skill is copied. Reproduce the source-to-destination behavior with the described PowerShell, ReadAllBytes/WriteAllBytes, and robocopy commands; done means a failed replacement leaves the existing skill intact and a successful copy replaces it safely.