A coding agent is asked to create a specification inside a change directory. The filename looks right, but a symbolic link along the path leads somewhere else. Checking the destination after writing may explain what went wrong; it cannot prevent the unwanted edit.
OpenSpec 1.14.3 addresses that ordering problem in its artifact creation workflows. The release was published on October 17 at 01:52 UTC, still October 16 in Brasília. It tightens instructions for agents that generate planning documents, particularly when teams customize schemas or delegate document creation to another tool.
Choose the destination before handing off the work
OpenSpec keeps proposals, specifications, design decisions and implementation tasks in reviewable files. Its workflows tell an agent how to create those artifacts. A schema can describe an output with a glob pattern rather than one fully specified filename.
The implementation discussion in PR #2104 makes the sequence explicit: select a concrete output path, check that it stays within the change directory, then create the artifact. That check must account for symbolic links in parent directories and in an existing destination file.
Delegation gets the same condition. When an instruction asks a separate skill or command to produce the artifact, the workflow says to invoke it only if it can write to the checked destination. Otherwise, the agent should stop. The revised workflow also avoids an unconditional template write that could overwrite the artifact a delegated tool has just produced.
For a team building its own workflows, the practical change is a more precise handoff: a pattern describing acceptable files becomes an agreed destination before another tool starts work.
Workflow guidance is one layer of the boundary
The reviewed code makes an important distinction: this part of the patch changes workflow instruction templates. Its associated tests check that the rules appear in the right order and remain consistent across skill and command variants.
Those tests do not establish that every agent will follow the instructions in every situation. Nor does the change turn OpenSpec into a filesystem sandbox. MnzAI Labs' assessment is that the patch removes a concrete operational ambiguity, while execution permissions, isolation and review still belong to the environment running the agent.
A delegated document needs an agreed delivery address as well as a description of its contents.
Teams with custom schemas can check that handoff in a disposable project. A successful run should mean both that the artifact was created and that it appeared at the authorized location.
Smaller fixes affect everyday use too
The release allows a capability's spec.md to link to another file inside the project while continuing to reject targets outside it. That is a project boundary, distinct from the tighter change-directory boundary used for artifact creation.
Other changes remove the braces dependency associated with an audit warning, cap excessively wide pattern expansions and prevent a validation spinner from hanging in certain hook environments. The release notes describe those fixes.
We reviewed the published release, diff and tests without reproducing an OpenSpec run. For existing users, the useful next step is to evaluate the update against their own schemas and delegated commands. Before an agent starts writing, can the team identify which process will create each file, where it will land and what authorizes that destination?