›_ Codex Issues
Codex Issues / #21477

/goal rejects long pasted input before Codex can normalize the objective

Resolved 💬 5 comments Opened May 7, 2026 by trevorprater Closed May 7, 2026
💡 Likely answer: A maintainer (github-actions[bot], contributor) responded on this thread — see the highlighted reply below.

What version of Codex CLI is running?

codex-cli 0.128.0

What subscription do you have?

Pro

Which model were you using?

GPT-5.5 xhigh

What platform is your computer?

Darwin 25.2.0 arm64 arm

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

Codex CLI/TUI. Terminal emulator should not affect this path.

What issue are you seeing?

The /goal slash command currently treats the slash-command argument as the final persisted ThreadGoal.objective and rejects it when the expanded objective exceeds MAX_THREAD_GOAL_OBJECTIVE_CHARS (4,000 chars).

That makes long pasted input unusable as the argument to /goal, even when the user intent is reasonable: paste a detailed task brief and let Codex turn it into a concise persisted goal. The current behavior blocks that flow before the model has a chance to normalize the source into a shorter goal.

The 4,000-character cap makes sense for the stored thread goal because it is persisted and repeatedly reinjected. It is less clear that the same cap should apply to raw user-provided /goal source text.

What steps can reproduce the bug?

  1. Enable the goals feature.
  2. Start a Codex CLI/TUI thread.
  3. Paste or type a /goal command whose expanded argument is longer than 4,000 characters, for example:
/goal <paste a detailed task brief longer than 4000 chars>
  1. Submit the command.

Current result: the TUI rejects the input and does not send anything to the model.

What is the expected behavior?

ThreadGoal.objective should stay bounded, but oversized raw /goal source text should be handled as source material for goal creation, not as the final stored objective.

A better flow would be:

  • If the expanded /goal argument is within the persisted objective limit, set the goal directly as today.
  • If the expanded argument exceeds the persisted objective limit but still fits a normal user turn, send a one-shot model turn asking Codex to normalize the source and call create_goal with a concise objective.
  • If the raw source is too large even for that normalization prompt, reject with a goal-specific error and preserve the pasted draft where possible.

Additional information

I have a proposed fix prepared in a fork branch, but this account could not open a PR against openai/codex via gh because GitHub rejected CreatePullRequest for the upstream repo.

Patch branch:
https://github.com/trevorprater/codex/tree/codex/normalize-long-goal-input

Upstream compare URL:
https://github.com/openai/codex/compare/main...trevorprater:codex/normalize-long-goal-input?expand=1

Fork draft PR carrying the patch:
https://github.com/trevorprater/codex/pull/1

Local validation on that branch:

just fmt
cargo test -p codex-tui goal_validation
cargo test -p codex-tui
just fix -p codex-tui

View original on GitHub ↗

5 Comments

github-actions[bot] contributor · 3 months ago

Potential duplicates detected. Please review them and close your issue if it is a duplicate.

  • #21258
  • #20598

Powered by Codex Action

etraut-openai contributor · 3 months ago

Thanks for reporting. This is already fixed on the main branch, and the fix will be included in 0.129.0.

trevorprater · 3 months ago

Thanks. I fetched current origin/main at 001363188a and I think #20746 fixed a related UX issue, but not the behavior reported here.

On current main, codex-rs/tui/src/chatwidget/goal_validation.rs still rejects expanded /goal input when actual_chars > MAX_THREAD_GOAL_OBJECTIVE_CHARS, and codex-rs/tui/src/chatwidget/slash_dispatch.rs still runs that validation before anything is sent to the model. The tests also still assert oversized /goal input is rejected (goal_slash_command_rejects_oversized_objective, goal_slash_command_rejects_large_paste_using_expanded_length, and the queued variant).

The issue I am reporting is narrower: the raw /goal argument is being treated as the final persisted ThreadGoal.objective. I agree the persisted goal should stay bounded, but long raw source text should be eligible for a one-shot model normalization turn that calls create_goal with a concise objective.

Is there another unreleased commit not visible on public main, or would you consider the normalization flow in this compare?
https://github.com/openai/codex/compare/main...trevorprater:codex/normalize-long-goal-input?expand=1

etraut-openai contributor · 3 months ago

The /goal feature is designed to support a limited-sized objective. If you have an objective that's longer than 4000 characters, you should write the objective to a file and refer to the file in the objective. The change in PR #20746 provides this guidance.

trevorprater · 3 months ago

Ok, thank you.

On Thu, May 7, 2026 at 2:42 AM Eric Traut @.***> wrote:

etraut-openai left a comment (openai/codex#21477) <https://github.com/openai/codex/issues/21477#issuecomment-4394716979> The /goal feature is designed to support a limited-sized objective. If you have an objective that's longer than 4000 characters, you should write the objective to a file and refer to the file in the objective. The change in PR #20746 <https://github.com/openai/codex/pull/20746> provides this guidance. — Reply to this email directly, view it on GitHub <https://github.com/openai/codex/issues/21477#issuecomment-4394716979>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAJY34EFIHJNCG5LUKNE5VD4ZQV5TAVCNFSM6AAAAACYT7UWH6VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHM2DGOJUG4YTMOJXHE> . You are receiving this because you authored the thread.Message ID: @.***>