Approving request_permissions in the TUI app-server path returns You did not grant additional permissions

What version of Codex CLI is running?

codex-cli v0.117.0

What subscription do you have?

Pro

Which model were you using?

gpt-5.4 xhigh fast

What platform is your computer?

Linux 6.8.0-106-generic x86_64 x86_64

What terminal emulator and version are you using (if applicable)?

Ghostty 1.3.1

What issue are you seeing?

When a tool calls request_permissions through the TUI app-server path with filesystem permissions, approving the prompt does not grant the requested permissions.

After selecting either:

1. Yes, grant these permissions
2. Yes, grant these permissions for this session

Codex reports:

You did not grant additional permissions

and subsequent shell commands still behave as if no extra permissions were granted.

The prompt I saw was:

Would you like to grant these permissions?

Reason: Need access to the repository’s .git metadata so I can stage and commit the verified fix.

1. Yes, grant these permissions (y)
2. Yes, grant these permissions for this session (a)
3. No, continue without permissions (n)

After choosing 1, Codex printed:

You did not grant additional permissions

One clue was that the prompt did not show the expected Permission rule: line for the requested filesystem paths.

What steps can reproduce the bug?

1. Start Codex TUI in a local git repository.
2. Trigger a tool call that uses request_permissions for filesystem write access through the app-server path. In my case this was write access to .git so the agent could run git add / git commit.
3. When the permissions prompt appears, choose either:

• 1. Yes, grant these permissions
• or 2. Yes, grant these permissions for this session

1. Observe that Codex responds with You did not grant additional permissions.
2. Observe that the requested filesystem permission was not actually applied.

What is the expected behavior?

Choosing option 1 or 2 should return the granted permission profile, preserve the requested filesystem paths, and allow subsequent shell commands to use the granted access.

The approval prompt should also display the expected Permission rule: line when filesystem permissions are present.

Additional information

I did a quick search and did not find an obvious duplicate issue in openai/codex.

I verified a local fix and it resolved the problem. The issue appears to come from lossy JSON round-trips in tui_app_server for permission request/response payloads. The app-server side uses camelCase fields like fileSystem, while the core side uses snake_case fields like file_system. When those payloads were round-tripped through JSON instead of converted with typed mappings, filesystem permissions could be dropped and turned into an empty permission profile.

Replacing those round-trips with typed conversions in the TUI request/response paths fixed the bug locally.

See also: https://github.com/openai/codex/compare/main...Mygod:fix-permission?expand=1