›_ Codex Issues
Codex Issues / #30051

Windows Codex Desktop tool execution fails with SetTokenInformation(TokenDefaultDacl) failed: 1344 on one user profile

Open 💬 3 comments Opened Jun 25, 2026 by murakamise0628-creator

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

OpenAI.Codex 26.616.10790.0

What subscription do you have?

ChatGPT Pro

What platform is your computer?

"$([Environment]::OSVersion | ForEach-Object VersionString) $([Environment]::Is64BitOperatingSystem ? 'x64' : 'x86')"

What issue are you seeing?

Codex Desktop tool execution fails only on my original Windows user profile.

Error:
SetTokenInformation(TokenDefaultDacl) failed: 1344

Environment:

  • Codex Desktop: OpenAI.Codex 26.616.10790.0
  • codex-cli: 0.142.2
  • Windows user where it fails: sei-new-2026031\user
  • A newly created Windows user profile on the same PC can run the same Codex Desktop tool test successfully.

Repro:

  1. Open Codex Desktop on the original Windows user profile.
  2. Start a new chat.
  3. Ask: "C:\Users\user\Downloads の先頭5件だけ確認して。余計なことはしないで。"
  4. Tool execution fails before file access.

Actual:
Codex Desktop fails while creating the tool execution process:
SetTokenInformation(TokenDefaultDacl) failed: 1344

Additional diagnostics:

  • CLI codex exec --sandbox read-only can run a PowerShell command after cleanup.
  • Codex Desktop still fails on the original user profile.
  • A new Windows user profile works, so this appears profile-specific.
  • The original profile's C:\Users\user\.codex ACL had many accumulated DENY entries for unresolved SIDs.
  • DENY ACL count increased after Desktop tool attempts, e.g. 34 -> 46.
  • logs_2.sqlite was about 646 MB and logs_2.sqlite-wal about 9 MB.
  • Tried Codex Desktop repair, reset, reinstall, TEMP/TMP change, .codex ACL reset, and log DB rotation. The Desktop error persists.

What steps can reproduce the bug?

Steps to reproduce:

  1. Open Codex Desktop on the affected Windows user profile: sei-new-2026031\user.
  2. Start a new chat.
  3. Ask Codex Desktop to run a minimal local read-only tool command, for example:

C:\Users\user\Downloads の先頭5件だけ確認して。余計なことはしないで。

  1. Codex Desktop attempts to create the tool execution process.
  2. Tool execution fails before any file access.

Observed error:
SetTokenInformation(TokenDefaultDacl) failed: 1344

Control test:

  1. Create a new Windows user profile on the same PC.
  2. Open Codex Desktop from that new user profile.
  3. Run the same minimal Downloads listing test.
  4. The tool execution succeeds there.

Additional notes:

  • codex-cli 0.142.2 can run a read-only sandbox command after cleanup.
  • Codex Desktop on the original Windows user profile still fails.
  • The affected profile's C:\Users\user\.codex ACL had many accumulated DENY entries for unresolved SIDs.
  • DENY ACL count increased after Desktop tool attempts, e.g. 34 -> 46.
  • logs_2.sqlite was about 646 MB and logs_2.sqlite-wal about 9 MB.
  • Tried Desktop repair, reset, reinstall, TEMP/TMP change, .codex ACL reset, and log DB rotation.

What is the expected behavior?

Codex Desktop should create the tool execution process successfully and list the first few files in Downloads.

The sandbox/tool runner should not fail with SetTokenInformation(TokenDefaultDacl) failed: 1344 on a Windows user profile, and repeated failed tool attempts should not accumulate stale DENY ACL entries under C:\Users\user\.codex.

Please advise how to safely clean/reset the Codex Desktop sandbox state for a single Windows user profile without migrating to a new Windows account.

Additional information

This may be related to sandbox user/token setup or stale ACL entries around the Codex Desktop local state.

Relevant local observations:

  • The same Windows machine works from a fresh Windows user profile, but fails from the original profile.
  • The affected profile had many stale/unresolved SID DENY ACL entries under C:\Users\user\.codex.
  • Repeated failed Desktop tool attempts appear to increase the DENY ACL count.
  • The local Codex log database had grown to:
  • logs_2.sqlite: about 646 MB
  • logs_2.sqlite-wal: about 9 MB
  • This resembles local state/sandbox cleanup issues rather than a general Windows, PowerShell, or filesystem permission problem.
  • I would prefer not to migrate to a new Windows user profile because the original profile contains my Codex history and working environment.

Please advise how to safely reset the Codex Desktop sandbox/local execution state for one Windows user profile.

View original on GitHub ↗

3 Comments

grsrzxgvmpg · 1 month ago

Likely the same root cause as #26438 — see https://github.com/openai/codex/issues/26438#issuecomment-5017572074 for a controlled differential + security-descriptor analysis. Short version: the failure triggers when the workspace-write cwd is the user-profile ROOT specifically (which uniquely carries a non-inheriting capability-SID ACE that inflates the derived token default DACL past its pre-allotted storage). "On one user profile" fits: the affected profile is the one codex is launched from ~ on, or whose root carries such an ACE. Workarounds: cd into any subdirectory/project dir first, or --sandbox read-only for read-only tasks.

LCABC777 · 1 month ago

This is the same root cause family as #26438 — see my detailed analysis there: https://github.com/openai/codex/issues/26438#issuecomment-5041543994

Short version for the Desktop/profile-specific symptoms you describe:

  • The accumulating deny ACEs for unresolved SIDs under ~/.codex come from cap_sid being persisted non-atomically by concurrent sandbox helpers (Desktop sessions + CLI). Torn reads make helpers

regenerate random capability SIDs, and each new SID adds fresh deny ACEs — which is why you saw the count grow (34 → 46) after every Desktop tool attempt.

  • Once the DACL on ~/.codex is bloated with hundreds of stale ACEs, workspace-write token creation hits SetTokenInformation(TokenDefaultDacl) failed: 1344 (ERROR_ALLOTTED_SPACE_EXCEEDED) on this

profile, while a fresh profile works — matching exactly what you observed.

  • Workaround that clears it immediately: remove the deny ACEs with unresolved SIDs from ~/.codex (or reset the folder ACL to inherited defaults), then kill any lingering codex-command-runner /

codex-windows-sandbox-setup processes from older sessions so the leak doesn't continue.

  • A working fix branch with a regression test is linked in the #26438 comment; happy to open a PR if invited.
chengjianyong9187 · 1 day ago

Similar failure shape here (Desktop-only code-mode host exited during
handshake, error 1344 surfaced as the underlying cause on 2026-08-26), but on
a profile with clean ACLs — no DENY-ACE accumulation on .codex, ~60 GB
free disk, no endpoint protection — which may rule out the ACL-pollution path
as the only trigger.

Two extra observations that might help narrow it down:

  1. Same-machine differential: with the same bundled runtime build, VS Code

extension sessions work flawlessly all day while Desktop sessions fail on
the first tool call; codex sandbox probes pass in all three sandbox modes
from a normal terminal. Only hosts spawned by the packaged Desktop app die.

  1. Desktop update 26.820.71523 (MSIX 26.820.9563.0) rebuilt the binaries

(SHA256 changed) but did not fix it — first post-update session reproduced
immediately.

Also relevant: read-only Desktop sessions CAN execute minimal commands
(pwd succeeds); workspace-write and even danger-full-access fail,
which suggests the host process exits before policy-specific token setup.