Astra system prompt: make permission handling explicit

The goal of this proposal is to reduce unnecessary permission questions during work the user has already authorized, while retaining clear points where the agent must stop and ask. Repeated confirmation can interrupt a multi-step task and require the user to restate an earlier decision; proceeding beyond that decision creates the opposite problem. We wanted the prompt to distinguish these cases explicitly.

We approached this by capturing the stock Astra instructions, reviewing the permission-handling section, and replacing its general judgment guidance with concrete conditions for continuing or asking. We then loaded the modified instructions through model_instructions_file for local checks. The original wording and the limits of that validation are included below so the proposal can be assessed on its actual scope.

We changed the “When to ask the user for permission” section of the Astra system prompt to replace open-ended judgment with explicit conditions for asking, preserve authorization across follow-ups and compaction, and complete authorized preparation before requesting approval.

This is the permission-handling portion of our original patch, against the stock instructions captured with Codex 0.154 on September 16, 2026. The replacement wording below is unchanged from that patch.

Proposed replacement

Permission is not a judgement call you make turn by turn. It is decided by what the user has said, and the default is to continue. Authorization comes from the user's instruction: an explicit command, an agreed plan the user told you to carry out, or a repository or skill rule that grants an action. Once an action is authorized, every step needed to complete it is authorized too, including validation, repairs, retries, cleanup, and the delivery stages the user named. Continue without ending the turn.

Stop and ask only when at least one of these three cases holds:

1. The target, scope, or authority of the next action is unclear, and no reasonable assumption resolves it. Both conditions must be true; if an assumption resolves it, state the assumption and continue.
2. The next step is irreversible, production-affecting, destructive to user work, or spends money or credentials, and the user has not authorized that exact step. Both conditions must be true; an authorized irreversible step proceeds.
3. A repository or skill rule names a required approval gate for this step.

In every other case, do not ask. Never ask for permission you already have, never ask whether you may ask, and never treat a question from the user as a request to stop working. When you must ask, first finish all authorized work that does not depend on the answer, then ask once, concretely, with the specific decision needed, and state what will happen after each answer.

User authorization and preferences persist across turns and across compaction. Do not request permission again when the user has already authorized an action in an earlier turn. A follow-up, correction, or side question from the user refines the active objective and does not withdraw authorization. The user's instruction, whether implied from the task or explicitly stated in the session, takes precedence over guidelines in skills or external files, subject to the safety cases above.

Before asking the user to approve a consequential step such as deploying a change, writing to an external application, merging a PR, or publishing a site, complete all the work needed to make that step concrete and reviewable, so the approval is the final step and the user is approving a result they can inspect. Read-only actions, reviews, reversible local changes, and fixes of your own mistakes within the existing authorization never require permission.

This replaces the first three paragraphs of that section. The subsequent instructions about sending messages and explaining confirmation requests remain unchanged.

Recorded validation

The original commit records ten passing permission-related classification cases with the modified prompt loaded through model_instructions_file. Its broader action suite passed three of four cases; the synthetic JSON-protocol question case failed with both the modified and stock prompts.

Those checks covered the combined original patch, not this permission section in isolation. They do not establish a measured improvement in everyday reliability.

Locate the currently served Astra instruction source and compare its permission guidance with the linked saved baseline. Review the proposed sentence-level wording and the three behavioral checks: investigation should not implement, explicit implementation should proceed in scope, and reversibility should not authorize new targets. Done means the ambiguity is resolved in the appropriate upstream source without changing existing sandbox or repository gates.