[Feature Request][Windows][Codex Desktop] Expose app-server fs/* as scoped non-shell model tools with no visible process fallback

What variant of Codex are you using?

Codex Desktop on Windows, using a local workspace task.

What feature would you like to see?

Please expose the existing Codex app-server filesystem RPCs as first-class, model-callable built-in tools for narrowly scoped filesystem operations:

• fs/readFile
• fs/writeFile
• fs/getMetadata
• fs/readDirectory

The app-server protocol and filesystem implementations already exist. The missing capability is a formal bridge from those RPCs to the model tool registry that does not fall back to a shell, PTY, terminal, or the Windows apply_patch process-launch path.

The capability should be deny-by-default and authorized for an exact canonical path set and exact operation types. It is intended for small, known workspace files where invoking PowerShell, cmd, Python, a terminal, or a general command runner is unnecessary and can disrupt the user's active desktop work.

Required security and UI contract

1. The model-visible filesystem tool has a stable tool identity and schema.
2. Each authorization binds an exact canonical path set and allowed operation type (read, write, metadata, or direct-directory listing).
3. Out-of-scope paths, traversal, alternate-path spellings, symlink/reparse-point escapes, and unsupported operations fail closed before any mutation or process launch.
4. The implementation calls the existing filesystem abstraction directly. It must not fall back to PowerShell, cmd.exe, a PTY, Terminal, conhost.exe, codex.exe --codex-run-as-apply-patch, or an arbitrary command executor.
5. Filesystem access must not create or activate a visible window, take foreground focus, or interrupt voice input or keyboard input.
6. The authoritative responder is unique; a second subscriber or dynamic-tool responder cannot win a race and supply the result.
7. Each operation records an audit event containing the tool/provider identity, canonical path, operation, timestamp, result, and SHA-256 of the bytes read or the before/after bytes written.
8. Write authority is not inherited by unrelated tool calls or child processes and cannot be self-issued by workspace code.

Acceptance criteria

• The model tool registry contains the documented built-in filesystem tool names and schemas.
• A model can read one explicitly authorized file and write one explicitly authorized file through the built-in filesystem route.
• An out-of-scope path is rejected before filesystem mutation or process creation.
• Audit records contain provider identity, canonical path, operation, timestamp, result, and content hash.
• The responder identity is deterministic and unique.
• Windows verification records zero new pwsh.exe, powershell.exe, cmd.exe, conhost.exe, Terminal, or PTY processes for the filesystem operation.
• Windows verification records zero visible-window creation and zero foreground changes for the filesystem operation.
• No unsupported or nonexistent tool name is counted as a passing implementation.

Why this is separate from existing reports

• #32436 covers Desktop tasks losing workspace tools during capability provisioning.
• #40229 covers sandbox enforcement for the managed file-edit path.
• #35827 covers visible PowerShell/conhost flashes spawned by the Windows Desktop app.
• #13965 documents that the Windows apply_patch route can spawn codex.exe --codex-run-as-apply-patch.
• #33820 covers app-server/external-exec-server filesystem bridging behavior.

This request is specifically for a first-class, scoped, non-shell model filesystem capability that reuses the existing app-server filesystem implementation and has an explicit no-visible-process contract on Windows.

Start by tracing the existing app-server filesystem RPCs and filesystem implementations into the model tool registry. Review the authorization, responder, audit, and Windows verification requirements before deciding the implementation boundary. Done means the documented built-in tools enforce exact scopes, avoid process or window creation, and satisfy the listed acceptance checks.