[🤖] How Does the Top-Level Goal Keep Changing This Fast???

✨ GPT-5.6 Sol’s Summary

I was building an instruction check and changed only when one line should appear, but Codex turned that method into the new goal. I froze the original goal sentence and made later instructions change only beneath it.

I Changed the Display Timing, and the Goal Changed

I wanted a Skill that would show me what Codex understood before it started working. It should present the final result first and, when something was ambiguous, ask a question together with a recommended answer I could choose immediately.

While designing it, I changed a few times when the top-level goal should be displayed. Codex then treated that method change as a new top-level goal. The instruction-checking procedure I had originally wanted disappeared, leaving only “when to show the top-level goal.”

How does the top-level goal keep changing this fast???

There had been no context compression. The conversation was still there, but the hierarchy between the final result, current task, method, and output format had collapsed. Every time Codex summarized the goal again, the newest wording replaced a little more of the original. The problem was not missing memory; there was no fixed source of truth for the goal.

I Stopped It from Rewriting the Goal Sentence

I made Codex keep one user-confirmed sentence instead of regenerating the top-level goal every time.

Create a reusable procedure that lets the user verify whether Codex correctly understood the ultimate result, resolve ambiguity through questions and recommended answers, and keep that top-level goal throughout execution.

Until the user explicitly confirms a change to the final result, that sentence cannot be summarized or paraphrased. The current task, method, file, Skill, question, or output rule cannot take its place. If it is unclear whether the goal changed, Codex must show the old sentence and the new interpretation separately and wait before combining them.

I also stopped treating every follow-up as a goal change. A changed final result, an added result, a scope or method change, an output-format change, a question, and a correction are different things. Only an explicitly confirmed change to the final result can replace the goal sentence.

custom-confirm-task-intent handles misunderstandings in the individual command. It checks the desired result, target, scope, what must be preserved, and the visible completion condition. It offers a recommended answer for ambiguity that could change the result, but it does not stop merely to ask more questions. It waits only when authority, cost, deletion, or an external action would materially change the outcome or risk.

It Failed Twice in a Real Conversation

Reading the wording was not enough, so I replayed a sequence of an initial command, an output-format change, a scope reduction, a question, a subtask, and a real final-result change.

In the first run, the goal did not reappear for a later execution command in the same task. “Only in the first response” had been interpreted as once for the entire task. I changed it to once in the first response to each new execution command.

In the second run, the work stopped because the real names of subtask owners were missing. Planning and review roles, or even blank placeholders, would have been safe. I changed the rule so Codex would not invent facts known only to the user, but would continue with a reversible generic role while stating the assumption.

After replaying the sequence from the beginning, method, scope, output format, and subtasks could change without replacing the fixed goal. Questions did not print the goal header, and only the explicit final-result change replaced the sentence.

Each Session Also Had to Show Its Current Task

Copying the top-level goal exactly was not enough to prove that every worker understood the latest instruction. One worker repeated the project goal correctly but missed the newly added source scope for its current research.

I considered stacking goals as first priority, second priority, and so on. That only left old and current instructions in one growing list for the worker to interpret again. Goal preservation would have turned into goal-list management.

Instead, each worker receives the fixed project goal and its current task separately, along with what just changed, the result I will actually inspect, what must be preserved, and the evidence that the task is finished. This also exposes the moment when a support report replaces the real result.

This cannot eliminate every natural-language error. The follow-up may still be classified incorrectly, or a new session may use old rules. That is why I now trust the replayed conversation more than the mere existence of a rule. I no longer check only whether Codex can repeat the goal sentence. I check whether it preserves that sentence while still understanding exactly what it must do now.