TUI: /side cannot access /permissions, and returning from /side can restore stale main-thread permissions

[adarshnagrikar14]

What version of Codex CLI is running?

codex-cli 0.122.0

What subscription do you have?

Plus

Which model were you using?

gpt-5.4 xhigh

What platform is your computer?

Microsoft Windows NT 10.0.26220.0 x64

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

CMD Terminal

What issue are you seeing?

Summary

I found two related TUI issues around /side:

1. /permissions is not available inside /side, even though it is useful there for switching between safe modes like Default and Read Only.
2. Returning from /side can restore stale main-thread permission state.

Actual behavior

• /permissions is blocked in /side.
• If permissions are changed in the main thread and /side is entered and exited, the main thread can show stale permissions again instead of preserving the current selection.

What steps can reproduce the bug?

There are two related repro paths.

Repro 1: /permissions is unavailable inside /side

1. Start a normal TUI session.
2. Start a side conversation with /side.
3. Inside the side conversation, try /permissions.
4. Observe that the command is unavailable / not accessible there.

Repro 2: main-thread permissions can reset after leaving /side

1. Start a normal TUI session.
2. In the main thread, change permissions using /permissions.
   Example: switch from Default to another mode and confirm the change.
3. Start a side conversation with /side.
4. Exit the side conversation and return to the main thread.
5. Observe that the main thread can show stale permission state again instead of preserving the updated value.

I reproduced this in the TUI. No special thread id was required.

What is the expected behavior?

• /permissions should be usable inside /side in a limited and safe form.
• Leaving /side should preserve the current main-thread permission mode.
• Returning from a side conversation should not replay stale permission state into the main thread UI/session state.

Additional information

I investigated the second bug locally and the issue appears related to stale cached thread-session state during thread replay when returning from /side.

The live permission update path changes the active app/chat state, but the cached session snapshot used for main-thread replay can remain stale. When /side exits and the main thread is restored, those old values can be replayed back into the UI/session state.

The two issues are related because /permissions inside /side is useful, but it also makes the stale-restore behavior more visible.

I have a working branch in my fork with a proposed fix: https://github.com/adarshnagrikar14/codex/tree/fix/side-permissions

If this approach aligns with maintainer expectations, I can open a PR from that branch.

[github-actions]

Potential duplicates detected. Please review them and close your issue if it is a duplicate.

• Resume replay can surface a stale assistant final message after restart from archived/removed subagent history #17487
• User turns can continue in completed subagent thread after parent spawned it, leaving subagent role active #18684

Powered by Codex Action

[etraut-openai]

/permissions is intentionally disallowed in /side, so I don't consider that a bug. The side conversation is intended to share the same permissions as the parent thread it's shadowing.

As for not restoring the main-thread permissions, I agree that's a bug. I'll work on a fix.

[adarshnagrikar14]

Thanks, that makes sense.

Understood on /permissions in /side being intentionally disallowed. I was treating that as a usability gap, but if the intended behavior is for /side to inherit and shadow the parent thread’s permissions, then I agree that part is not a bug.