How to Stop GPT-6 Astra From Changing Files You Didn’t Ask It to Touch
Use Astra on existing codebases without losing scope, history or test discipline.
Brightory creates practical AI guides and workflows based on research, testing, and documented AI usage patterns.
Constrain the edit surface before Astra writes anything: name the allowed files, name protected files or directories, require a pre-edit plan, and reject any change outside that boundary unless it asks first.
Why this problem happens
Astra is designed to handle complex end-to-end coding work and to adapt when requirements change. That makes explicit scope boundaries more important, not less: stronger agency does not remove the need to define what is authorized.
What is confirmed about GPT-6 Astra
OpenAI describes GPT-6 Astra as its flagship model for complex reasoning and coding, with stronger codebase understanding and support for software-engineering workflows. The API model page lists a 1,050,000-token context window and 128,000 maximum output tokens. Those specifications describe capacity; they do not mean every repository should be loaded in full.
Use a change boundary workflow
- List the files it may edit and the files it must not touch.
- Ask for a read-only inspection first.
- Require a file-by-file plan.
- Approve the plan before edits.
- Afterward, ask for a changed-files summary and diff review.
A prompt structure that makes the workflow auditable
Task: Stop the model From Changing Files You Didn’t Ask It to Touch Hard constraints: - Treat the existing project or evidence set as the source of truth. - Do not expand scope silently. - Mark anything unsupported or unverified. - Before acting, restate the relevant constraints and the verification plan. Return: 1. Preflight findings 2. Planned actions 3. Work completed 4. Verification evidence 5. Remaining uncertainty
What not to do
Do not use vague instructions such as ‘fix the project but don’t change too much.’ A model cannot reliably infer which unrelated changes you consider acceptable.
How to verify the result
Before finishing, verify that every changed file was named in the approved plan and that behavior outside the requested feature still passes its checks.
When to use a simpler workflow
If this is a workflow you repeat, the main cost is not understanding the method once—it is rebuilding the controls every time. The paid kit packages this pattern into reusable codebase control assets so you can start from a defined process instead of a blank prompt.
Need durable repository rules for an AI coding agent? Use the free AGENTS.md Generator to define commands, edit boundaries, conventions and definition of done.
Turn this fix into a reusable system.
The method for stopping GPT-6 Astra From Changing Files You Didn’t Ask It to Touch is easier to maintain when the checks, prompts and handoff steps live in one repeatable workflow. The Brightory GPT-6 Astra Workflow Kit packages this kind of work into reusable research, verification, handoff, prompting and QA workflows, so you can carry the method into the next project instead of starting over.
Code change-control benchmark
A coding edit is successful only when the requested behavior changes, protected behavior remains stable and the diff can be explained file by file.
- Inspect before editing. Identify entry points, dependencies, tests and state ownership.
- Write a change contract. Requested behavior, likely files, protected files and acceptance tests.
- Reproduce bugs before fixing them.
- Keep the blast radius observable. Reject unrelated cleanup unless required for correctness.
- Run targeted tests, then regression tests.
Acceptance test
Require a reviewable diff, successful targeted verification, no unexplained out-of-scope changes and a list of anything that could not be tested.
Decision rule
Treat the model like a contributor under change control, not an omniscient code generator.
Code-edit failure matrix
| Failure | Signal | Correction |
|---|---|---|
| Patch is too large | Unrelated files or cleanup appear. | Revert unrelated edits and narrow protected scope. |
| Cause is unproven | No reproduction existed before the patch. | Recreate the failure and verify the proposed cause. |
| Regression | Target test passes but neighboring behavior breaks. | Test callers, shared state and interfaces. |
| Completion without evidence | “Done” has no test output or diff summary. | Require verification evidence and unresolved risks. |
Worked example: keep the patch causal
A save bug appears only after editing an existing item. Record that reproduction first, then trace the likely path through the handler, validation, API and persistence layer. Protect unrelated styling and list-rendering files.
The acceptable fix should explain the observed failure and alter only the necessary path. After the targeted test passes, rerun creation, unchanged saves, validation failures and any nearby operation sharing the same persistence code. A large refactor that happens to remove the symptom is weaker evidence than a small causal patch with tests.
Operational notes for this workflow
Before editing, ask the model to identify the ownership path for the behavior: entry point, shared state, interfaces, tests and likely files. Compare that plan with the repository before granting permission to patch. If the proposed file list expands during implementation, require an explanation before accepting the extra scope.
Verification should include the exact target behavior plus at least one nearby regression path. For stateful code, check both the happy path and a failure/retry path. Preserve test output and diff summary in the handoff so the next session starts from evidence rather than confidence language.
- OpenAI — GPT-6 Astra release
- OpenAI Developers — GPT-6 Astra model specification and pricing
- OpenAI Developers — latest model guide
- OpenAI API changelog
Model availability, subscription allowances, pricing and interface controls can change. Re-check the linked official pages before relying on a current limit or price.