codex - 💡(How to fix) Fix Support per-project Fast Mode / speed-tier configuration [1 comments, 2 participants]

Official PRs (…)
ON THIS PAGE

Recommended Tools

×6

Utilities matched from this issue’s tags and category — try them while you read without losing context.

GitHub issue graph ai analysis

Paste a GitHub issue URL. We fetch that issue, discover linked issues from bodies/comments/timeline, collect linked pull requests, and produce a structured English report.

The report is written in English Markdown for sharing and archival.

Helpful · Quick feedback

Loading…
GitHub stats
openai/codex#20203Fetched 2026-04-30 06:32:04
View on GitHub
Comments
1
Participants
2
Timeline
5
Reactions
0
Author
Timeline (top)
labeled ×3closed ×1commented ×1

Please add a supported way to enable Fast Mode / speed-tier behavior for only selected repositories or projects, without changing the global Codex default for every workspace.

A concrete use case: keep the normal thorough/default Codex behavior globally, but allow a specific repository such as /home/thijs/Documents/werk_tue/aifaa/epv_possession_sequence to start in Fast Mode by default.

Error Message

  • The config schema rejects misspelled/unknown keys with a clear error, consistent with the existing config behavior.

Root Cause

Please add a supported way to enable Fast Mode / speed-tier behavior for only selected repositories or projects, without changing the global Codex default for every workspace.

A concrete use case: keep the normal thorough/default Codex behavior globally, but allow a specific repository such as /home/thijs/Documents/werk_tue/aifaa/epv_possession_sequence to start in Fast Mode by default.

Fix Action

Fix / Workaround

There is a workaround using a repo-local .codex/config.toml with profile = "...", but that is not the same as a first-class per-project Fast Mode setting. It also means users need to model Fast Mode indirectly through model/reasoning/profile choices, and it does not expose the same product-level speed-tier behavior as the Fast Mode UI.

Code Example

pub struct ProjectConfig {
    pub trust_level: Option<TrustLevel>,
}

---

let active_profile_name = config_profile_key
    .as_ref()
    .or(cfg.profile.as_ref())
    .cloned();

model_reasoning_effort: config_profile
    .model_reasoning_effort
    .or(cfg.model_reasoning_effort),
model_verbosity: config_profile.model_verbosity.or(cfg.model_verbosity),

---

[projects."/path/to/repo"]
trust_level = "trusted"
fast_mode = true

---

[projects."/path/to/repo"]
trust_level = "trusted"
speed_tier = "fast"

---

[projects."/path/to/repo"]
trust_level = "trusted"
profile = "fast"
RAW_BUFFERClick to expand / collapse

Summary

Please add a supported way to enable Fast Mode / speed-tier behavior for only selected repositories or projects, without changing the global Codex default for every workspace.

A concrete use case: keep the normal thorough/default Codex behavior globally, but allow a specific repository such as /home/thijs/Documents/werk_tue/aifaa/epv_possession_sequence to start in Fast Mode by default.

Current behavior

Codex currently supports project entries in ~/.codex/config.toml, but the project-specific config surface is limited to trust metadata. In the installed CLI source for codex-cli 0.125.0, ProjectConfig only contains trust_level:

pub struct ProjectConfig {
    pub trust_level: Option<TrustLevel>,
}

The active project is resolved from the current working directory or git root, but that project object is only used as project metadata. Model, reasoning effort, and verbosity are resolved from CLI/profile/global config instead:

let active_profile_name = config_profile_key
    .as_ref()
    .or(cfg.profile.as_ref())
    .cloned();

model_reasoning_effort: config_profile
    .model_reasoning_effort
    .or(cfg.model_reasoning_effort),
model_verbosity: config_profile.model_verbosity.or(cfg.model_verbosity),

There is a workaround using a repo-local .codex/config.toml with profile = "...", but that is not the same as a first-class per-project Fast Mode setting. It also means users need to model Fast Mode indirectly through model/reasoning/profile choices, and it does not expose the same product-level speed-tier behavior as the Fast Mode UI.

Desired behavior

Allow Fast Mode to be configured per project/repository. For example, one of these shapes would be enough:

[projects."/path/to/repo"]
trust_level = "trusted"
fast_mode = true

or:

[projects."/path/to/repo"]
trust_level = "trusted"
speed_tier = "fast"

or a project profile binding in the user config:

[projects."/path/to/repo"]
trust_level = "trusted"
profile = "fast"

The key requirement is that a user can opt one repo into Fast Mode while leaving all other repos on the normal default.

Impact

Users often have a small number of repositories where latency matters more than maximum depth, and other repositories where the opposite is true. A global Fast Mode toggle forces users to repeatedly switch modes or accept the wrong default for part of their work.

Per-project Fast Mode would make Codex defaults match the actual risk/latency profile of each codebase. It would also make the existing [projects] table more useful without requiring users to create shell aliases or remember --profile flags.

Acceptance criteria

  • Codex supports a documented per-project way to opt into Fast Mode or the fast speed tier.
  • The setting applies automatically when the session cwd is inside the configured project or its git worktree/root.
  • The setting does not affect other repositories.
  • CLI flags and explicit model/profile selections still take precedence over project defaults.
  • The config schema rejects misspelled/unknown keys with a clear error, consistent with the existing config behavior.
  • Documentation explains the relationship between global defaults, project defaults, profiles, and explicit CLI/TUI selections.

Environment / evidence

  • Codex CLI version observed locally: codex-cli 0.125.0.
  • Installed package metadata points to openai/codex, package @openai/codex.
  • Relevant local source observations:
    • codex-rs/core/src/config/mod.rs: ProjectConfig only contains trust_level.
    • codex-rs/core/src/config/mod.rs: active project lookup is separate from profile/model resolution.
    • codex-rs/core/src/config/profile.rs: profiles support model, sandbox, reasoning effort, verbosity, and related config, but project entries do not bind to those settings directly.

extent analysis

TL;DR

To enable Fast Mode for specific repositories, extend the ProjectConfig struct to include a fast_mode or speed_tier field and update the config parsing logic to apply this setting when the session cwd is inside the configured project.

Guidance

  • Extend the ProjectConfig struct to include a fast_mode or speed_tier field, e.g., pub struct ProjectConfig { pub trust_level: Option<TrustLevel>, pub fast_mode: Option<bool>, }.
  • Update the config parsing logic to apply the project-specific fast_mode or speed_tier setting when the session cwd is inside the configured project.
  • Introduce a new config key, such as fast_mode or speed_tier, in the [projects."/path/to/repo"] table to allow users to opt-in to Fast Mode for specific repositories.
  • Ensure that CLI flags and explicit model/profile selections still take precedence over project defaults.

Example

// Example extension of ProjectConfig
pub struct ProjectConfig {
    pub trust_level: Option<TrustLevel>,
    pub fast_mode: Option<bool>,
}

// Example config snippet
[projects."/path/to/repo"]
trust_level = "trusted"
fast_mode = true

Notes

The proposed solution requires changes to the codex-rs source code, specifically the ProjectConfig struct and config parsing logic. The exact implementation details may vary depending on the existing codebase and requirements.

Recommendation

Apply workaround by creating a repo-local .codex/config.toml with a profile key that binds to a Fast Mode profile, until a per-project Fast Mode setting is implemented. This allows users to opt-in to Fast Mode for specific repositories while leaving the global default unchanged.

Vote matrix · Quick signals

Works
Did the solution work? Tap to confirm.
Easy Fix
Was it a quick fix?
Time Saver
Did it save you time?
Blocking
Was it severely blocking?
Common Issue
Are others likely hitting this too?
Flaky / Intermittent
Is it intermittent?
Verified / Reproducible
Can you reproduce it reliably?
Loading…

Still need to ship something?

×6

Another batch ranked right after the header list — different links, same matching logic.

Back to top recommendations

TRENDING

codex - 💡(How to fix) Fix Support per-project Fast Mode / speed-tier configuration [1 comments, 2 participants]