Add configurable basename display for command approval notifications

What variant of Codex are you using?

Codex CLI/TUI 0.153.0 on NixOS.

What feature would you like to see?

Add an opt-in TUI setting that controls whether command-approval notifications show the full executable path or only its basename:

[tui]
notification_command_display = "basename"

Supported values would be:

• "full" — current behavior and the default, preserving backward compatibility.
• "basename" — replace only argv[0] in the notification preview with its filename before applying the existing shell quoting and truncation.

For example:

Approval requested: /run/current-system/sw/bin/git ...

would become:

Approval requested: git ...

The full command shown in the approval UI, the approval payload, and the command eventually executed must remain unchanged.

Reasoning

On NixOS, executable paths commonly start with /run/current-system/sw/bin/ or a long /nix/store/.../bin/ path. Approval notifications currently truncate the rendered command to 30 graphemes, so the executable path consumes the useful part of the notification. Multiple notifications can therefore look effectively identical even when they request different commands.

This should be opt-in rather than unconditional: the full path can be useful security context when distinguishing executables. Keeping "full" as the default preserves current behavior.

Reproduction

1. Configure approval notifications:

   [tui]
   notifications = ["approval-requested"]
   notification_method = "osc9"
   notification_condition = "always"
   

2. Run Codex on NixOS.

3. Trigger an action requiring approval whose executable is resolved to a NixOS system or store path.

4. Observe that the desktop notification starts with Approval requested: /run/current-system/sw/bin/... (or /nix/store/...) and truncates before the useful command context.

Proposed patch

The current flow joins the complete event command in handle_exec_approval_now, then the notification renderer truncates that string to 30 graphemes.

A minimal implementation would:

1. Add a NotificationCommandDisplay enum (Full, Basename) to codex-rs/config/src/types.rs, serialized as lowercase.
2. Add notification_command_display to TuiNotificationSettings with Full as its serde/default value.
3. When constructing the notification preview, clone the command vector and, only in Basename mode, replace its first element using std::path::Path::file_name(). Fall back to the original token when no filename is available.
4. Pass that preview through the existing shlex::try_join and truncation path. Do not mutate ev.command.
5. Regenerate config.schema.json and add focused config/rendering tests for the default and opt-in modes.

Acceptance criteria

• An absent setting and notification_command_display = "full" produce today's notification text.
• notification_command_display = "basename" shortens only the executable token; arguments remain present and quoted as today.
• Bare executable names remain unchanged.
• The approval UI, approval payload, and executed command retain the original full path.
• The generated config schema documents the new option.

Additional information

The repository's contributing guide says external code contributions and pull requests are not accepted, so this issue includes the proposed implementation rather than an external PR.

Start with handle_exec_approval_now in codex-rs/tui/src/chatwidget/tool_requests.rs and the notification renderer in codex-rs/tui/src/chatwidget/notifications.rs. Then inspect TuiNotificationSettings and related types in codex-rs/config/src/types.rs, along with existing config and rendering tests. Done means the default and full modes preserve current text, basename mode changes only the preview executable, and config.schema.json documents the option.