/goal + superpowers:brainstorming: assistant self-loops, generating ~150 duplicate clarifying questions without user input

Resolved 💬 3 comments Opened May 8, 2026 by intovery Closed May 8, 2026

💡 Likely answer: A maintainer (etraut-openai, contributor) responded on this thread — see the highlighted reply below.

What version of Codex CLI is running?

codex-cli 0.129.0

What subscription do you have?

Plus

Which model were you using?

gpt-5.5 (reasoning effort: medium)

What platform is your computer?

Microsoft Windows NT 10.0.26200.0 x64

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

Warp

What issue are you seeing?

Under an active /goal, after the assistant uses the
superpowers:brainstorming skill and asks a single clarifying
question, it fails to yield the turn to the user. Instead, it
generates ~150+ additional assistant turns by itself, each one
a slightly rephrased version of the same confirmation question,
with no user message in between any of them. Tokens are
consumed continuously. The goal-mode timer reached 840 seconds
before I manually interrupted by sending a user message.

Concrete pattern observed:

The assistant asks a normal clarifying question once

(e.g., "Should I name it <name>?").

Without any user reply, it then produces another assistant

turn rephrasing the same question
("Shall I proceed?", "Confirm please?", "Awaiting reply", ...).

This continues indefinitely. Wording varies every turn;

semantics are identical. The model is genuinely re-generating
each turn (not buffer replay).

Tokens are consumed on every turn.
The loop terminates instantly upon any user message. At that

point the assistant correctly recognizes the bug and apologizes:
"I sent the same confirmation question repeatedly. My turn
control got tangled."

This appears to be a turn-yield bug specific to the
"ask one question first" flow of superpowers:brainstorming
under an active /goal. The goal-continuation runtime seems
to treat the absence of a user reply as "still working" and
keeps the model generating, instead of yielding and waiting.
Because each generated turn is itself an assistant message,
the loop never observes the user reply that would break it.

What steps can reproduce the bug?

Enable goals: [features] goals = true in config (or via

/experimental).

Start a /goal for a brainstorming-style task that requires

the assistant to scaffold something new (e.g., "create a mini
side-project under <some path> that demonstrates X").

The assistant invokes the superpowers:brainstorming skill

and asks one normal clarifying question
(e.g., "Should I name it <name>?").

Do not reply. Wait silently.
Observe: the assistant generates a new turn on its own,

asking essentially the same question with slightly different
wording.

The self-generated turns continue indefinitely. In my session,

~150+ turns accumulated over ~14 minutes before I broke the
loop by sending any user message.

Uploaded thread: 019e084e-399c-79a1-af82-d9657d78787c

What is the expected behavior?

After asking a clarifying question, the assistant should yield
the turn and wait silently for the user. No further assistant
turns should be generated until the user replies.

Concretely:

One clarifying question = one assistant turn, then stop.
Goal-mode continuation should not re-trigger the model when

the previous turn ended with an unanswered user-facing question.

If a continuation watchdog must run, it should detect "last

turn was a user-facing question awaiting reply" and skip the
continuation, rather than generating another turn.

Additional information

Related but distinct issues:

#21176 — /goal marks objective as done prematurely.

Different: in my case the goal never starts working at all;
it stays in the clarifying-question phase.

#20656 — Plan mode silently suppresses goal continuation

with 0 tokens consumed. Different: tokens are actively
consumed here, and Plan mode was off.

#20591 / #20598 — explicit thread/goal/set errors.

Different: no error is surfaced; the loop runs cleanly from
the user's perspective.

Debugging hints from the session:

The repeated questions are semantically identical but

lexically varied (~150 unique rephrasings). This rules out
a stuck output buffer being replayed and points to the model
being re-invoked each turn with a context that signals
"still need confirmation."

The instant recovery on user input suggests the bug is

isolated to the "no user reply yet → keep generating" path;
once a user message arrives, normal turn-taking resumes
immediately and the assistant explicitly acknowledges the
loop was a malfunction.

Skills active during the loop: superpowers:brainstorming,

superpowers:using-superpowers. The loop began immediately
after superpowers:brainstorming was invoked for the first
clarifying question.

Goal-mode timer at the point of interruption: ~840 seconds.

View original on GitHub ↗

3 Comments

etraut-openai contributor · 3 months ago

This is by design. The /goal feature is intended to be used for problems where you want the agent to work autonomously for long periods of time on an objective without user input.

It sounds like you have a different use case in mind, so I recommend not using /goal in this case.

Tuo-Luo · 3 months ago

I documented a related workaround here: #23067.

The approach is to make repeated blocking conditions part of the goal completion criteria up front, so /goal can terminate the continuation loop when it keeps hitting the same blocker, without treating the blocked action itself as completed.

hanohrs · 23 days ago

@etraut-openai

Thanks for clarifying that /goal is currently intended for autonomous work
without user input.

I reproduced the same behavior in the Codex CLI with a minimal interactive
example. When the model requests user input through an ordinary assistant
message, the turn completes and the thread becomes idle. Because the goal
remains active, the runtime starts another continuation turn, causing the model
to repeat the unanswered question while continuing to consume tokens.

There is already a partial workaround. First, edit ~/.codex/config.toml to
enable request_user_input in Default mode:

[features]
default_mode_request_user_input = true

Then explicitly instruct the model to use the tool whenever input is required:

/goal Play one game of Nim with me.

Start with 7 stones. We alternate removing 1, 2, or 3 stones.
You move first. The player who removes the final stone wins.

On my turns, always call `request_user_input` with exactly three options:
1 stone, 2 stones, or 3 stones.
Complete the goal after declaring the winner.

With this configuration and explicit instruction, the model uses
request_user_input and waits for the response instead of entering the
automatic continuation loop.

This workaround suggests that human-in-the-loop goal execution is technically
possible within the existing architecture. However, users currently need to
know about a feature flag that is still under development and explicitly instruct
the model to use the tool.
If the model requests input through an ordinary assistant
message instead, there is still no runtime safeguard against repeated
continuation turns.

Human input seems like a typical part of long-running goals—for example,
clarifying an unexpected ambiguity discovered during implementation or
providing information that cannot be obtained from the repository.

Could support for these cases be reconsidered? Two complementary approaches
seem possible:

Make request_user_input available and recommended during active goals.
Add a WaitingForUser goal or turn outcome. This would support

conversational human-in-the-loop interactions that do not use the
structured request_user_input UI, while preventing goal continuation until
the user provides the required input.

Even if fully interactive goals remain outside the intended scope, suppressing
automatic continuation when the agent is explicitly waiting for required user
input would prevent this failure mode and avoid unnecessary token consumption.