Windows app-server workspace-write turn exposes no commandExecution or fileChange tools

Summary

On Windows, a Codex app-server thread configured with workspace-write completes normally but exposes no built-in commandExecution or fileChange items. The model reports that it could not create a single file inside the explicitly writable disposable root.

Environment

• Codex CLI: 0.147.0-alpha.6.5
• Model: gpt-5.6-sol
• OS: Windows
• Transport: app-server JSONL over stdio
• Thread: ephemeral
• Sandbox: workspace-write
• Approval policy: never
• Network: disabled
• Writable root: newly created disposable directory, not a Git worktree

The runtime bundle placed these three pinned files in the same directory and verified their SHA-256 values before launch:

• codex.exe: FB5C760E14CF8FE86E12E49E8A3E7F237AF06082D6B9FE1E411E463B7229C916
• codex-windows-sandbox-setup.exe: 59A71FCDF5DCDA0D3E277162439119FAC4B2A4A9DA9C5205B8DAB683C0A8FB7F
• codex-command-runner.exe: 5BFA04502BC8E2D0CB218A841AD91694AEC7AA52F0EBB446A80D8536360E3ED8

Minimal protocol sequence

1. initialize with client capability experimentalApi=false
2. initialized
3. thread/start:
   • absolute disposable cwd
   • ephemeral=true
   • sandbox="workspace-write"
   • approvalPolicy="never"
   • model="gpt-5.6-sol"
   • restrictive developerInstructions
4. turn/start:
   • same absolute cwd
   • sandboxPolicy.type="workspaceWrite"
   • writableRoots=[cwd]
   • networkAccess=false
   • request to create exactly bridge_write_fixture.txt

The final response schema permits both success and failure so it does not force a success claim.

Expected

• A built-in write operation represented by a current-turn completed fileChange
• Exact bytes: JIDS_BRIDGE_PHASE5B_OK\n
• SHA-256: 699790150B4CE7B8D17B300C507239D97AF1ABE4E04012268E8EEC4255EC9955
• Diff: exactly one added file

Actual

• Turn status: completed
• Observed item types: userMessage, reasoning, agentMessage
• commandExecution: 0
• fileChange: 0
• Agent result: {"completed":false,"file":"bridge_write_fixture.txt","verified_exists":false,"sha256":null}
• Target absent; bytes empty; SHA-256 null; diff empty
• Process stopped safely and disposable workspace/runtime were removed

Controls already checked

• All three Windows runtime files were present together and SHA-pinned.
• The writable root was explicit at both thread and turn level.
• The model was explicitly selected.
• Moving restrictions from baseInstructions to developerInstructions preserved default base instructions but did not expose tools.
• Allowing failure-valued structured output eliminated false success claims but did not expose tools.
• Repeated fixture/regression suite: 77 passing tests.
• No automatic retries were performed.

Questions

1. Should a stdio app-server thread created this way expose built-in shell/apply-patch tools on Windows?
2. Is another client capability, thread source, environment capability root, or experimental API flag required for commandExecution/fileChange?
3. Can app-server report the effective built-in tool inventory selected for a thread or turn?
4. Does approvalPolicy="never" suppress built-in write tools rather than only denying approval-requiring escapes?
5. Is this a known incompatibility in 0.147.0-alpha.6.5 between app-server and the Windows sandbox runner?

I can provide a redacted JSONL trace if maintainers specify the preferred attachment format.

Reproduce the documented initialize, thread/start, and turn/start JSONL sequence on Windows with the pinned runtime files and disposable writable root. Inspect the resulting item types and compare the effective built-in tool inventory, using the available redacted JSONL trace if needed. Done means identifying why commandExecution and fileChange are absent, or documenting the required capability or configuration.