GPT-6 Astra keeps stopping? Simplify AGENTS.md and Skills

If GPT-6 Astra stops and asks questions more often than GPT-5.6 Sol, first decide whether the answer could materially change the outcome. If it could, the clarification is appropriate. If the model asks permission before reading a file, returns a plan instead of making an already authorized change, or runs the entire test suite after a documentation edit, the likely cause is the loaded instruction set: AGENTS.md, a nested override, or an overly broad Skill.

OpenAI describes both sides of Astra’s behavior. The model is more likely to clarify decisions that can affect the result, and it follows long instructions more precisely. As a result, an ambiguous or conflicting rule in a Skill or AGENTS.md can exert more influence. The fix is to inspect the actual chain, keep only durable rules at each level, and replay the same bounded task.

As of September 6, 2026, the exact gpt-6-astra model is listed in BetterToken’s GPT group and can be connected to the official Codex app through a custom provider over the Responses API.

Connect GPT-6 Astra to Codex through BetterToken

The current setup is in the BetterToken Codex guide. BetterToken supplies the API connection; your configuration and task determine which instructions Codex loads and when Astra asks a question.

Find every instruction the model actually sees

Codex assembles its instruction chain when a session starts. Under the official AGENTS.md discovery rules, it reads:

1. the global AGENTS.override.md, or the global AGENTS.md when no override exists;
2. at most one instruction file per directory from the project root to the current working directory, trying AGENTS.override.md, then AGENTS.md, then each configured project_doc_fallback_filenames entry until it finds the first non-empty file;
3. rules closer to the working directory later in the chain, so they can override earlier guidance.

Empty files are skipped. Combined project instructions are limited by project_doc_max_bytes, 32 KiB by default. A long root file can crowd out the narrower file that matters to the current task.

Start a new session from the same directory and ask Codex to list the loaded sources in order:

codex --ask-for-approval never "List the instruction sources you loaded."

Next, inspect project_doc_fallback_filenames and find every fallback file that could have been selected along the path. Record the active Skills and the source of each selected Skill as well: Codex can discover them in repository, user, admin, and system locations. Do not edit anything until this baseline is written down.

Label every rule with four questions

Field	Question
Scope	Does it apply to every repository, this project, or one directory?
Trigger	Which specific task should activate it?
Action	What must Codex do?
Stop	Must it stop and wait for the user?

Rules without a clear trigger often cause unnecessary stops:

• Always ask before making changes blocks even reversible local edits.
• Use every relevant skill may load several overlapping processes.
• Run all tests before finishing expands verification regardless of change size.
• Do not make assumptions forbids routine decisions that do not alter the outcome.
• multiple files claim that their own rule has the highest priority.

Keep a stop condition when missing input can genuinely change the result or authorization: an irreversible deletion, publication, paid operation, incompatible architecture choice, or missing secret. Reading files, making a scoped local edit, and running a targeted test usually need no extra approval after the user has assigned the task.

Keep AGENTS.md durable and short

A problematic root file tries to prescribe every possible situation:

AGENTS.md

- Always ask the user before changing any file.
- Always create a detailed plan and wait for approval.
- Use all available skills that may be relevant.
- Run the full test suite after every change.
- Never make assumptions.
- Never stop until everything in the repository is fixed.

These rules conflict on autonomy, scope, and testing. The last line also expands one task to the entire repository.

A more useful root file establishes outcome and boundaries:

AGENTS.md

## Working agreement

- Complete the user's requested outcome with the smallest correct change.
- Treat the user's current instruction as higher priority than reusable workflow guidance.
- Make routine, reversible assumptions when they do not change the requested outcome; state material assumptions.
- Ask only when a missing choice would materially change the result or authorization.
- Preserve unrelated work and do not expand scope to optional cleanup.
- Run checks proportionate to the changed behavior; broaden only when evidence justifies it.
- Stop after the requested result and relevant checks are complete.

This is not a universal template. Add durable package commands, commit conventions, and real prohibitions. Put service-specific rules closer to that service. If you use a temporary AGENTS.override.md, remember that it replaces AGENTS.md in the same directory; it does not extend it. Copy every still-required rule into the override, or use a nested AGENTS.md for a narrower scope, then remove the temporary override after the experiment.

Decide what belongs where

AGENTS.md should contain agreements that apply to nearly every task in its scope: ownership, package manager and required check, preservation of user changes, approval boundaries, and final report format.

Keep an infrequent multi-step workflow in a narrow Skill. Put deterministic parsing, formatting, or schema validation in a script or hook. Move large examples and reference material into references/ so they are not loaded until the Skill is selected.

Content	Location
Durable project-wide rule	root AGENTS.md
Rule for one directory or service	nested AGENTS.md or AGENTS.override.md
Infrequent workflow with a specific trigger	one narrow Skill
Parsing, formatting, and schema checks	script or hook
Detailed documentation and examples	the selected Skill’s references/

Narrow Skill descriptions

Codex Skills use progressive disclosure. The model first sees the name and description; it reads the full SKILL.md only after selecting the Skill. A description such as “use for any development task” can therefore activate an unnecessary workflow.

Give each Skill one job and put its trigger and boundary first:

---
name: release-preview
description: >-
  Use only when the user asks to build a local release preview; do not publish,
  deploy, push, or change production state.
---

Keep imperative steps, exact inputs and outputs, and real stop conditions in SKILL.md. Move large examples to references and deterministic actions to scripts:

Release preview

## Inputs

- One validated article payload.
- A clean local preview checkout.

## Workflow

1. Build the preview from the supplied payload.
2. Verify title, body, links, and images locally.
3. Return the preview path and stop.

## Stop conditions

- The payload is missing or invalid.
- The task requires production publication; request separate authorization.

Test the description with one prompt that should activate it and two nearby prompts that should not. If two Skills activate for the same request, separate their triggers or merge the duplicate workflows. Remove a rule from the root when it is needed only inside one Skill.

State autonomy, precedence, and test scope explicitly

In the Astra guidance, OpenAI recommends four explicit behaviors: carry an implied request through to a finished result; prioritize the user’s current instruction over generic Skill guidance; ask only when an answer materially changes the outcome; and choose verification according to change risk instead of repeating broad suites without new evidence.

Place one concise working agreement at the appropriate level instead of copying a long block into every Skill. Add a subagent rule only when the workflow actually uses delegation, with a trigger such as independent subtasks, sufficient workload, and a clear way to merge results. A blanket “always use multiple agents” creates a different problem for small tasks.

Compare before and after on one fixture

Choose a small task with objective acceptance:

Update one configuration field in docs/setup.md, preserve all unrelated files,
run the Markdown link check for that file, and report the changed path.

Run it from the same directory with the same model, permissions, and clean state. Record questions before the first edit, whether user input was required, loaded instruction files and Skills, checks performed, and unrelated changes.

Improvement does not mean zero questions at any cost. A good setup asks about material choices, proceeds through routine decisions, runs sufficient checks, and preserves task boundaries. If behavior does not change, inspect the current directory, nested overrides, duplicate Skills, and whether the session was restarted.

We did not run this controlled replay on a user’s repository while preparing the article, so no fixed reduction in questions is promised. The method provides observable evidence for separating model behavior from a specific instruction and keeping only rules that improve the result.