`app-server` drops global `-c` overrides when another `-c` appears after the subcommand

What version of Codex CLI is running?

codex-cli 0.147.0

What subscription do you have?

ChatGPT Pro

Which model were you using?

Not applicable. The reproduction only calls experimentalFeature/list and does not start a turn.

What platform is your computer?

Linux 6.18.44 x86_64 unknown (NixOS)

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

Ghostty 1.3.1

Codex doctor report

Not included. The reproduction uses an empty temporary CODEX_HOME, does not require authentication, and does not start a model turn.

What issue are you seeing?

codex app-server silently drops every global -c / --config override placed before the app-server subcommand when any -c is also placed after the subcommand.

This works:

codex -c 'features.default_mode_request_user_input=true' app-server

experimentalFeature/list reports:

{
  "name": "default_mode_request_user_input",
  "enabled": true,
  "defaultEnabled": false
}

Adding an unrelated override after app-server causes the earlier override to disappear:

codex -c 'features.default_mode_request_user_input=true' app-server \
  -c 'suppress_unstable_features_warning=true'

The same request now reports:

{
  "name": "default_mode_request_user_input",
  "enabled": false,
  "defaultEnabled": false
}

This affects more than feature flags. Settings such as model_provider, custom model_providers, model defaults, approval policy, and sandbox mode can all be silently discarded.

The documented configuration precedence says CLI flags and --config overrides have the highest precedence: https://learn.chatgpt.com/docs/config-file/config-basic#configuration-precedence

What steps can reproduce the bug?

1. Create a clean Codex home:

   export CODEX_HOME="$(mktemp -d)"
   

2. Start app-server with only a global override:

   codex -c 'features.default_mode_request_user_input=true' app-server
   

3. Send these JSON-RPC messages over stdin, waiting for the initialize response before sending initialized:

   {"id":1,"method":"initialize","params":{"clientInfo":{"name":"config-repro","version":"0"},"capabilities":{"experimentalApi":true}}}
   {"method":"initialized"}
   {"id":2,"method":"experimentalFeature/list","params":{"cursor":null,"limit":null,"threadId":null}}
   

4. Find default_mode_request_user_input in response id: 2. It has enabled: true.

5. Stop app-server and repeat with an unrelated post-subcommand override:

   codex -c 'features.default_mode_request_user_input=true' app-server \
     -c 'suppress_unstable_features_warning=true'
   

6. Send the same JSON-RPC messages. default_mode_request_user_input now has enabled: false.

What is the expected behavior?

Codex should retain both sets of overrides in CLI order. The second command should apply both:

features.default_mode_request_user_input=true
suppress_unstable_features_warning=true

At minimum, Codex should not silently discard valid overrides based on whether they appear before or after the subcommand.

Additional information

Moving every override after app-server works around the bug:

codex app-server \
  -c 'features.default_mode_request_user_input=true' \
  -c 'suppress_unstable_features_warning=true'

Possibly related to #26436, which added app-server -c support, but that PR does not cover mixing overrides before and after the subcommand.

Start by tracing app-server argument parsing and configuration override merging, reproducing the two commands from the issue with a temporary CODEX_HOME. Verify that overrides before and after the subcommand are retained in CLI order, including the reported feature flags, and add or run coverage for both command forms.