Why

item/permissions/requestApproval sends a requested permission profile to app-server clients. The core profile already stores filesystem permissions as entries, but the v2 compatibility conversion used the legacy read/write projection whenever possible and left entries unset.

That made the request ambiguous for clients that consume the canonical v2 shape: permissions.fileSystem.entries was missing even though filesystem access was being requested. A client that rendered or echoed grants from entries could treat the request as having no filesystem permission entries, then return an empty or incomplete grant. The app-server intersects responses with the original request, so omitted filesystem permissions are denied.

What Changed

• Populate AdditionalFileSystemPermissions.entries when converting legacy read/write roots for request permission payloads, while preserving read and write for compatibility.
• Mark read and write as transitional schema fields in the generated app-server schema.
• Add regression coverage for the v2 conversion, the app-server item/permissions/requestApproval round trip, and TUI app-server approval conversion expectations.
• Refresh generated JSON and TypeScript schema fixtures.

Verification

• just fmt
• cargo test -p codex-app-server-protocol
• cargo test -p codex-app-server request_permissions_round_trip
• cargo test -p codex-tui converts_request_permissions_into_granted_permissions
• cargo test -p codex-tui resolves_permissions_and_user_input_through_app_server_request_id