/goal should define how goal mode interacts with inherited approval policies
Summary
The main issue is that /goal did not make its execution semantics explicit with respect to standing repo/AGENTS approval policy.
Thread id: b0a36c35-4e7e-4141-8392-266e6d305d52
What happened
My standing repo/AGENTS workflow policy distinguishes commit-ready from commit-approved and normally requires explicit approval before staging/committing a unit.
In the original task, I asked the agent to create a goal for itself to complete the docs/plans all the way through. In ordinary language, that is already a goal-scoped execution directive: continue implementing the provided plans until the final work unit is complete, making closed units durable as needed, unless something materially unsafe or out of scope appears.
However, even after /goal was active, the agent still treated the inherited repo-local “explicit commit approval required” policy as a separate hard gate requiring another user message. So the goal runner kept telling the agent to continue toward completion, while the agent kept preserving a standing approval gate that required absent user input.
That created an ambiguous middle state: /goal kept running, but the agent would not take the normal durable action required to progress the goal. The result was repeated blocked-state messages and token usage without progress.
Expected behavior
/goal should define how goal mode interacts with inherited repo/AGENTS approval policies. It should not leave the agent to infer whether ordinary repo-local approval gates still require a separate user message.
A goal should establish one of these modes explicitly:
- Goal grants scoped autonomy: continue through routine repo-local approval gates needed to complete the goal, as long as checks/reviews pass and no forbidden/destructive action is involved; or
- Goal preserves approval gates: treat any repo-local “requires user input/approval” gate as an automatic pause/completion condition for the goal, report once, and stop.
Either default would be better than the current implicit conflict.
Why this matters
The conflict was not an obvious user-authored contradiction in the immediate goal prompt. The approval behavior came from standing repo/AGENTS workflow policy. When /goal is activated, the feature should make its policy precedence clear to the agent and user.
If /goal preserves approval gates, then “blocked awaiting user approval” should become a goal pause condition automatically. If /goal overrides routine approval gates, that should also be explicit.
The key request is not simply “users should avoid conflicting instructions.” The /goal feature should define how goal mode interacts with standing repo/AGENTS approval policy, especially when the user’s goal prompt already asks for autonomous completion of the plan/work through durable closure.
5 Comments
Can you say more about what you mean by "user-only approval gate"? Are you talking about a sandbox approval prompt or some other guidance that you provided to the agent in your prompt or AGENTS.md file to stop and ask you for permission?
If it's the latter, then the behavior you're seeing is expected because you're giving the agent conflicting instructions. In using the
/goalfeature, you're telling the agent to keep going until the objective is achieved. If you also give it separate instructions to stop for conditions that are not stipulated in the objective completion criteria, then the agent will continue to try to achieve the goal and repeatedly run into a block due to the other instructions.If we were to change
/goalto do as you're suggesting, the agent will often stop if it perceives that it's blocked for whatever reason. That would defeat the purpose of the/goalfeature.My recommendations are to:
/goalfeature for use cases that may require user feedback or approvalsThe key issue is that the conflict was not obvious user-authored contradiction in the immediate goal. The stop-for-approval behavior is part of my standing repo/AGENTS workflow policy. When
/goalis activated, the feature should make its execution semantics explicit to the agent with respect to those standing policies.In other words,
/goalshould not leave the agent to infer whether ordinary repo-local approval gates still require a separate user message. It should automatically establish one of these modes:Either default would be better than the current implicit conflict. If
/goalpreserves approval gates, then “blocked awaiting user approval” should become a goal pause condition automatically. If/goaloverrides routine approval gates, that should also be explicit. What failed here is that neither policy was made explicit, so the loop kept trying to satisfy an objective while preserving a standing approval gate that required absent user input.So I don’t think the fix is simply “users should avoid conflicting instructions.” The
/goalfeature should define how goal mode interacts with standing repo/AGENTS approval policy.I documented a related workaround here: #23067.
The approach is to make repeated blocking conditions part of the goal completion criteria up front, so
/goalcan terminate the continuation loop when it keeps hitting the same blocker, without treating the blocked action itself as completed.Same issue here: 019e3850-e3ab-7ff0-8132-57b3f57e33a1
Went on for 8 hours without any progress.
I've updated the
/goalimplementation to give the agent the ability to mark the goal status asblockedwhen it hits an impasse. This should prevent the behavior you described above.