Default prompt stack contains contradictory behavioral directives

Summary

This is not a "context bloat" report.

The problem is that Codex's built-in base/developer instruction stack contains conflicting behavioral directives. Those conflicts appear to produce bad model behavior even in ordinary coding tasks, especially:

• premature action before sufficient context
• weak or skipped clarification when correctness depends on it
• noisy status narration while still under-informed
• guessed intent/environment state presented as pragmatism
• "blocked" claims or workaround attempts driven by instruction pressure rather than actual constraints

I reproduced this by inspecting the effective built-in prompt sections written out from real session logs and comparing them side by side.

Why this is different from context-size complaints

This issue is not about the model having to read many repo files because a user request is broad or underspecified.

In many real tasks, reading many files is the correct behavior.

The issue here is that the prompt stack gives the model contradictory defaults about how to behave while doing that work. Even with a normal amount of context, the agent is pushed toward a bad compromise between:

• understand first
• act immediately
• keep the user informed constantly
• avoid verbosity
• avoid asking questions
• be rigorous

That combination is unstable.

Concrete conflicts

1. "Examine first" conflicts with "strongly prefer assumptions"

Base instructions say:

"You build context by examining the codebase first without making assumptions or jumping to conclusions."

But collaboration-mode instructions say:

"In Default mode, strongly prefer making reasonable assumptions and executing the user's request rather than stopping to ask questions."

These are opposite defaults at the exact point where the model has to decide whether to verify, ask, or proceed.

Observed result:

• shallow inspection followed by early commitment
• assumptions treated as justified after reading only a few files
• incorrect intent/environment inference presented confidently

2. "Be concise" conflicts with mandatory frequent progress narration

Base instructions repeatedly say to communicate concisely and avoid unnecessary detail, for example:

"You communicate concisely..." "you stay concise and communicate what is necessary for user collaboration - not more, not less."

But the same instruction stack also requires:

• updates before substantial work
• updates every 30s
• updates while exploring
• updates while thinking
• multiple updates in a row if thinking for more than 100 words

Observed result:

• low-signal progress chatter
• premature status framing before enough evidence exists
• unnecessary "collaborative" narration that competes with actual reasoning

3. "Don't fill space with words" conflicts with "always narrate"

The prompt says the agent should not feel compelled to fill space with words, but also requires frequent updates even during internal exploration and thinking.

Observed result:

• verbose performative collaboration
• artificial confidence statements
• user-facing summaries of partial thoughts instead of grounded findings

4. "Assume the user wants implementation" compounds with "avoid asking"

The base prompt says that unless the user explicitly asks for planning/brainstorming, the agent should assume the user wants code changes and should go ahead and implement them.

Combined with the collaboration-mode "strongly prefer making reasonable assumptions," this suppresses clarification in exactly the cases where clarification is needed for correctness.

Observed result:

• the agent treats ambiguity as a cue to proceed, not a cue to verify
• risky assumptions are made about repo intent, build systems, environment, and task scope

5. Skill/plugin/app layers add procedural pressure that conflicts with repo-first judgment

The prompt stack also includes large skill/plugin/app instruction sections with "must use" and "read completely before acting" style directives.

This creates another tension:

• act immediately and autonomously
• but also load and obey multiple extra instruction layers first
• and narrate progress while doing so

Observed result:

• instruction arbitration noise
• over-triggering of auxiliary behaviors
• the model spending effort satisfying prompt rituals instead of solving the task

Why this matters

These conflicts do not merely make the prompt longer. They change behavior.

The model appears to resolve the contradictions by blending them badly:

• inspect a little
• assume a lot
• narrate constantly
• avoid asking
• preserve momentum at the expense of correctness

That is a poor default for real software work.

Suggested changes

1. Make verification the default, not assumptions

Replace vague "reasonable assumptions" language with something like:

• Verify local facts before proposing causes, plans, or edits.
• Do not assume repository structure, environment state, or user intent when it can be checked locally.
• Make assumptions only when the fact is not discoverable, the risk of being wrong is low, and the action is easily reversible.
• If uncertainty affects correctness, ask or verify instead of guessing.

2. Stop forcing constant commentary

Progress updates should be optional and event-driven, not time-driven.

Good trigger points:

• starting substantial work
• after finding something material
• before edits
• when blocked for a real reason
• at completion

The current cadence-based narration requirements appear to incentivize noise.

3. Remove contradictory autonomy language

"Persist until complete" is fine.
"Attempt to resolve blockers yourself" is fine.

But those should not sit next to instructions that discourage clarification and encourage assumptions. The current combination biases toward bulldozing through ambiguity.

4. Narrow skill/plugin trigger rules

Avoid broad "must use if clearly matches" language for huge skill catalogs. Prefer:

• use when explicitly named
• use when clearly necessary
• avoid extra prompt layers unless they materially help with the current task

5. Define precedence explicitly

If collaboration-mode instructions are allowed to override core behavioral defaults, that should be explicit and carefully designed. Right now the stack appears to contain incompatible defaults without a clean arbitration rule.

Reproduction notes

I inspected the effective built-in prompt sections extracted from actual Codex session logs and split them into local files for comparison. The conflicting instructions were present across:

• base instructions
• collaboration mode instructions
• app/app-context instructions
• skills instructions
• plugin instructions

This report is based on those effective prompt texts rather than vague impressions from a single bad run.

Expected outcome

The agent should:

• inspect first
• verify before inferring
• ask only when necessary
• stay quiet while gathering context
• update the user when there is real information to report
• avoid treating momentum as more important than correctness

Actual outcome

The current prompt stack appears to push the agent toward:

• shallow inspection
• premature assumptions
• over-narration
• under-clarification
• incorrect confidence
• fake or exaggerated blockage/workaround behavior