OpenSpec explained: turn an AI coding request into reviewable artifacts
OpenSpec security and operations: plans are instructions, not permissions
Review repository guidance, edit scope, telemetry and shared planning data before agent execution.
What you will learn
- Treat imported planning text as untrusted
- Review telemetry and sensitive context
- Recover from a bad generated change
Before you start
- Basic Git and Node knowledge
- A disposable sample repository
Display dependencies and missing evidence without automatically executing the next instruction.
Key takeaways
- Plans can carry unsafe instructions.
- Metadata cannot enforce filesystem isolation.
- Shared stores expand the data-access review.
Treat imported planning text as untrusted
A proposal or community schema may contain commands and file paths. Review them before allowing an assistant to execute actions. A convincing requirement paragraph cannot grant access to secrets or authorize changes outside the requested project.
The inspected action-context function publishes allowedEditRoots metadata but does not enforce host permissions. Use the assistant’s real permission controls and an isolated worktree; do not rely on a JSON field as a security boundary.
Review telemetry and sensitive context
The README says telemetry records command names and version, and documents opt-out through configuration or environment variables. That is the documented policy, not a network capture performed for this series.
Keep credentials and customer data out of specs and examples. A standalone store shared by Git may broaden who can read a plan. Review repository access, redacted fixtures and retention before moving sensitive planning material into a shared location.
Recover from a bad generated change
Pause agent execution, preserve the diff and identify whether the bad instruction came from the proposal, generated guidance or imported schema. Restore only the affected files you own after reviewing legitimate concurrent work.
Re-run application tests and review the acceptance scenarios after recovery. Marking an artifact complete or restoring its text does not reverse external actions an assistant may already have taken. Those need separate operational handling.
Decision guide
| Criterion | Option A | Option B |
|---|---|---|
| Best when | You need predictable behavior and easy auditing | You need adaptive optimization and have reliable telemetry |
| Main risk | May leave performance on the table | Can become difficult to explain or debug |
Implementation steps
- 1
Review imported instructions and command scope.
- 2
Apply real host permissions and telemetry preferences.
- 3
Preserve evidence before selective restoration.
Copy-ready example
openspec config set telemetry.enabled false
# Review project changes before an assistant applies them:
git diff --stat
git diffFrequently asked questions
Does allowedEditRoots sandbox the assistant?
The inspected function only constructs metadata; actual host permissions are separate.
Was telemetry traffic measured?
No. The article reports the README policy and documented opt-out.
Sources
- OpenSpec / README.mdSource checked 2026-09-23
- OpenSpec / src/core/change-status-policy.tsSource checked 2026-09-23