Codex CLI repeatedly interrupts long prompts with “Conversation interrupted”
Description
Codex CLI repeatedly aborts a conversation while submitting a long, structured implementation prompt. The CLI displays:
Conversation interrupted - tell the model what to do differently. Something went wrong? Hit `/feedback` to report the issue
This happened more than once in a fresh Codex session.
Uploaded thread
Thread ID from the generated feedback link:
019fd90d-0df2-7921-b151-52f1949d9f45
Environment
- Codex CLI on a remote Linux HPC login node
- Shell session over SSH
- Model command used:
codex -m gpt-5.6-terra -c 'model_reasoning_effort="high"'
Steps to reproduce
- Start a fresh Codex CLI session.
- Submit a long, highly structured prompt containing many sections, constraints, paths, and validation requirements.
- Wait for Codex to process the prompt.
- The conversation is interrupted before the task completes, and the CLI shows the error above.
- Repeating in a new session can produce the same interruption.
Expected behavior
Codex should either process the full prompt, reject it with a clear size/context-limit message, or preserve the session and ask the user to shorten/split the request.
Actual behavior
The conversation terminates with a generic interruption message and no clear indication whether the cause is prompt length, transport failure, model failure, or session instability.
Impact
This makes long, governance-heavy implementation tasks unreliable and forces the user to restart the conversation and manually split prompts into multiple parts.
Suggested improvements
- Show the underlying error category when possible.
- Warn before submission if the prompt is too large.
- Preserve the session and allow retrying the same prompt.
- Provide a built-in way to submit a long prompt in multiple acknowledged parts without starting execution early.
I can provide additional CLI version, logs, or terminal output if needed.
1 Comment
Closing this issue because it was created from a misunderstanding of the generated feedback URL. The URL was a prefilled bug-report form containing an uploaded-thread reference, not an existing diagnosis of the underlying interruption.