[max-sixty]

The Codex commit-message example passed -c system_prompt='', which Codex 0.156.1 rejects under --strict-config as an unknown setting. It also implied an empty prompt, though global AGENTS.md and Codex's other context remain.

The single recommended command now uses Luna without reasoning, limits project instructions and the skills catalog, disables unneeded web, shell, app, plugin, subagent, and goal capabilities, and replaces built-in model instructions with a one-character file. It preserves user provider settings and authentication. Accepting Worktrunk's first-run Codex setup creates that file and reports its path; the FAQ inventories it and explains that the saved command requires it. File setup errors name the path. Config help, the sample config, benchmark command, generated skill docs, and snapshots use the same command.

For Reply exactly OK., the one-character file reduced a normal-home Codex query from 27,890 to 24,371 input tokens in one comparison. In a separate normal-home comparison, skills.max_context_tokens=1 reduced input from 24,572 to 18,208 tokens; the four shell/app/plugin disables reduced that to 16,352, agents.enabled=false to 14,339, and disabling goals to 13,721. codex debug prompt-input showed the skills catalog shrinking from 22,170 to 501 characters. In a controlled fresh home, the global AGENTS.md added 6,504 tokens. We found no supported per-command flag to omit global AGENTS.md while retaining the normal Codex home; remaining agent context keeps this above a tens-of-tokens prompt.

Validated the exact saved stdin → Codex → jq command with strict config parsing and the user's normal Codex home: Fix typo in README, 13,729 input and 8 output tokens. Nine PTY commit prompt cases cover creation, reuse, preview decline, and setup failure; docs sync, help snapshots, docs build, and pre-commit passed.

The remaining direct-query work is tracked in #4264.

This was written by Codex on behalf of max-sixty

[worktrunk-bot]

This command is written into a user's config, not just shown in docs. LlmTool::recommended_config reads it from dev/config.example.toml, and the first-run "Configure Codex for commit messages?" prompt saves it. Because a saved command outlives the Codex version it was tested against, two of the new flags turn version drift into failed commits. One way out is to keep the persisted command version-tolerant and put the strict, fully locked-down variant in llm-commits.md as an opt-in.

[max-sixty]

we only want one example. Is there no single flag for expressing most of this?

[worktrunk-bot]

This commit makes Worktrunk write a file into another tool's config directory, ~/.codex/worktrunk-commit-instructions.txt, but the FAQ's "What files does Worktrunk create?" inventory doesn't list it. AGENTS.md (Data Safety) names that FAQ section as the inventory. The Config files table there (next to the ~/.config/worktrunk/approvals.toml row) needs a row for it, with what creates it (accepting the first-run Codex prompt) and how to remove it. That row should also say the saved Codex command stops working if the file is removed.

The earlier --strict-config / --ignore-user-config concern no longer applies, because neither flag is in the command now.

Superseded by the review on a later commit.

[worktrunk-bot]

codecov/patch fails on this head with 8 missed lines in src/output/commit_generation.rs (59/67 patch lines hit). The FAQ and the Created/Keep output addressed the earlier findings, so the coverage gap is the only reason the approval is withdrawn: AGENTS.md (Coverage) makes codecov/patch a merge gate that needs explicit approval to override.

The Codex paths the tests don't reach are:

• The ? preview notice ("Uses {}; creates a one-character file there if absent"). test_user_requests_preview runs only with a fake claude. A Codex variant that answers ? then n covers it and also checks that declining the preview creates no file.
• Ok(false) => {}, when the instructions file already exists. Writing ~/.codex/worktrunk-commit-instructions.txt into the temp home before the prompt in test_user_accepts_codex_prompt covers it, and the test can assert that Created Codex instructions is absent while the Keep … hint still prints.
• The Err(e) arm (Codex setup failed: {e:#} plus return Ok(false)). The unit test covers the path-naming error, but the prompt's handling of it isn't tested. Making ~/.codex a regular file in the temp home and accepting reaches it, and the test can assert that the config was not written.

These are mechanical PTY tests next to test_user_accepts_codex_prompt. I can push them if you'd like.

codecov/patch failed — 8 uncovered Codex setup lines; see the follow-up review.

[worktrunk-bot]

The new --disable flags bring back the version-drift failure that dropping --strict-config removed. Codex validates every --disable name: FeatureToggles::validate_feature in codex-rs/cli/src/main.rs does anyhow::bail!("Unknown feature flag: {feature}") for a name that isn't a known feature key. goals isn't in the feature list at rust-v0.120.0 (April 2026); it first appears by rust-v0.130.0. On an older Codex, a user who accepted the first-run prompt gets a failed message generation on every wt step commit / wt merge.

-c features.<name>=false sets the same config (the --disable help text says it is "Equivalent to -c features.<name>=false"). Without --strict-config, an unknown key there goes into the flattened entries map of FeaturesToml and is ignored, so older versions just leave that tool on. Upstream already keeps removed feature names valid for --disable, so this mainly protects older installs.

The suggestion below changes the source line. The other copies need the same edit: Taskfile.yaml, the recommended_config inline snapshot in src/output/commit_generation.rs, and the regenerated docs and help snapshots (test_docs_are_in_sync).

Superseded by the review on a later commit.