Fix: Add missing config support for execpolicy auto-allow prefixes

[ignatremizov]

Fix: Add missing config support for execpolicy auto-allow prefixes

Bug Report

Issue: PR #7033 by @zhao-oai implemented TUI prefix allowance infrastructure (the (p) option in approval prompts), but the feature was incomplete: it provided no way to configure prefix allowances via config file before execution.

User Impact: Despite the TUI showing prefix-based approval options, users couldn't pre-configure commonly approved command patterns, forcing them to repeatedly approve safe commands during sessions.

History: This has been a highly requested feature for over a year:

• Closes Make the list of auto-approved commands configurable via execpolicy #1260 (opened June 6, 2025, 👍 57 reactions)
• Completes the last unchecked P2 item in Rust CLI Cutover (Burndown List) #1262 (Rust CLI Cutover burndown)
• Multiple users requested Cursor CLI-style auto-approval configuration
• My recent user feedback (Dec 10, 2025): prefix selection needed improvement for commands like database connections

What was broken

1. ❌ No config schema for execpolicy.auto_allow_prefixes
2. ❌ No mechanism to load prefix rules from config at session start
3. ❌ Users had to manually approve repeated safe commands despite TUI infrastructure being present
4. ❌ Prefix detection in TUI captured too much (e.g., full psql command instead of just the prefix before the -c flag)

How this fixes it

Core Changes

• Config schema: Added execpolicy.auto_allow_prefixes array field in ConfigToml and new ExecPolicyConfigToml type
• Policy loading: Implemented apply_auto_allow_prefixes() to parse and apply prefix rules from config at session start
• Tokenization: Uses shlex::split() to parse prefix strings into argv for execpolicy prefix rules (properly handles shell quoting)
• Error handling: Gracefully logs warnings for empty/invalid prefixes without failing startup
• Layer precedence: Respects config layer ordering (project > user > global), allowing per-project overrides
• Tests: Comprehensive test coverage including:
  • Prefix matching with trailing arguments
  • Config layer precedence (project overrides user)
  • Empty and malformed prefix handling
  • Non-matching commands still require approval

Documentation

• Updated config.md with usage examples
• Added execpolicy_auto_allow_prefixes.md with full spec

Code CI changes

• Refactored ScrollInputMode and ReadMode to use #[derive(Default)] with #[default] attribute (removes manual implementations)
• Fixed shell.rs test comparisons to use Path::new() instead of PathBuf::from() for better clarity

This was due to running the suggested just fix -p codex-core commands.

Usage Example

Users can now configure auto-approved command prefixes in ~/.codex/config.toml or .codex/config.toml:

[execpolicy]
auto_allow_prefixes = [
  # Git commands
  "git add",
  "git commit",
  
  # GitHub CLI (read-only operations) (especially graphql queries)
  "gh api",
  "gh issue list",
  "gh pr list",
  "gh pr view",
  "gh repo view",
  "gh run list",
  "gh workflow list",
  
  # Package manager queries
  "npm list",
  "npm view",
  "pip list",
  "pip show",
  "cargo search",
  "cargo tree",
  
  # Test runners that use cache outside the current working directory
  "go test ./...",
  "golangci-lint run",
  "cargo test",
  "npm test",
  
  # API inspection
  "curl -X GET",
  "http GET",
  
  # Database queries (addresses my feedback from #1260)
  "PGPASSWORD=dev_pass psql -h 127.0.0.1 -p 5432 -U dev_user -d dev_db -c",
]

Afterwards commands like git add . or cargo test --all-features will be auto-approved without prompting.

Testing

All tests pass:

cargo test -p codex-core
just fmt
just fix -p codex-core

Test Coverage

✅ Prefix matches allow commands with additional trailing arguments
✅ Project config overrides global config as expected
✅ Invalid/empty prefixes are safely ignored with warnings
✅ Non-matching commands still require approval
✅ Proper shell tokenization (handles quotes, spaces, env vars)

Addressing User Feedback

This PR directly addresses my feedback from #1260:

#1260 (comment)
#1260 (comment)

Scope & Limitations

In Scope

✅ Completes execpolicy prefix allowance implementation from #7033
✅ Affects exec command approvals only
✅ Session-based (rules loaded at startup, not persisted to disk)
✅ Respects config layer precedence

Out of Scope

❌ No changes to apply_patch or other tool approvals
❌ No modifications to existing execpolicy rule files
❌ No persistence beyond current session (in-memory rules only)
❌ No TUI-based prefix detection improvements (addressed in config instead)

Related Work

• Implements config mechanism missing from whitelist command prefix integration in core and tui #7033
• Depends on execpolicy prefix rule infrastructure from earlier work
• Does not conflict with TUI (p) option (both can coexist)
• Follow-up needed: app-server protocol v2 support (noted by @owenlin0 in whitelist command prefix integration in core and tui #7033)

Checklist

• Tests added and passing
• Documentation updated
• Code formatted with just fmt
• Linter checks pass with just fix -p core
• Links to bug report (Make the list of auto-approved commands configurable via execpolicy #1260) and burndown issue (Rust CLI Cutover (Burndown List) #1262)
• Addresses user feedback from issue comments
• Follows Conventional Commits format
• CLA signed (per CONTRIBUTING.md)

---

Community Requested: This completes a highly requested feature with 57+ 👍 reactions over 7 months.

[github-actions]

All contributors have signed the CLA ✍️ ✅
_{Posted by the CLA Assistant Lite bot.}

[ignatremizov]

I have read the CLA Document and I hereby sign the CLA

[etraut-openai]

Thanks for the contribution. We've updated our contribution guidelines to clarify that we're currently accepting contributions for bugs and security fixes, but we're not generally accepting new features at this time. We need to make sure that all new features compose well with both existing and upcoming features, fit into our roadmap, and are consistent across all Codex surfaces (CLI, IDE extension, web). If you would like to propose a new feature, please file or upvote an enhancement request in the issue tracker. We will generally prioritize new features based on community feedback.

We are actively working on a design for extending the existing exec policy "rules" feature. Any new features or additions need to fit into that design. If you have suggestions for new capabilities (like prefix support), please open a new feature request or post to an existing request.

[ignatremizov]

Ah, thank you. I am taking a look at the rules feature, was not immediately visible. There may be a bug in how environment variables are being parsed as part of the existing auto allow prefixes execpolicy rule amendments feature then that I'll try to fix.

Edit:
Bare env assignments like PGPASSWORD=... psql ... are parsed as a single token, not separate arguments. This causes prefix matching to capture the entire command as one "word".

Workaround 1: Use env explicitly

prefix_rule(
  pattern = ["env", "PGPASSWORD=dev_pass", "psql", "-h", "127.0.0.1", "-p", "5432",
             "-U", "dev_user", "-d", "dev_db", "-c"],
  decision = "allow",
)

Workaround 2: Set environment in config, approve command only

# ~/.codex/config.toml
[shell_environment_policy]
set = { PGPASSWORD = "dev_pass" }

# ~/.codex/rules/postgres.rules
prefix_rule(
  pattern = ["psql", "-h", "127.0.0.1", "-p", "5432", "-U", "dev_user", "-d", "dev_db", "-c"],
  decision = "allow",
)

I don't see a need to fix this at present. Thanks again