Errors and compatibility
User-facing errors expose code, message, and retryable. Internal causes and credentials are not part of the public projection. retryable does not authorize replaying a non-idempotent operation such as creating a Run or repeating an uncertain effect.
Request and service errors
Error instances can override catalog defaults. Inspect the actual returned code and retryability.
Run and execution errors
These are common categories, not an exhaustive list of all package-defined business errors. Inspect the Run cursor, logs, and Workflow context for the specific cause. Failure after a successful earlier commit does not undo that commit.
CLI and client errors
CLI_INIT_TARGET_NOT_EMPTY protects existing files. Use a new or empty initialization directory.
CLI_OUTPUT_EXISTS protects an existing export. Review it before opting into --overwrite. CLI_ARTIFACT_EXPORT_FAILED means local output publication failed; it does not change stored results.
PROJECT_CONNECTION_FAILED, PROJECT_REQUEST_FAILED, PROJECT_RESPONSE_INVALID, and PROJECT_CLIENT_CLOSED belong to the Node.js client boundary. Query existing work after an uncertain request instead of creating another Run automatically.
Compiler errors are documented in Compiler reference.
Compatibility checklist
- Match the Workflow protocol, currently
2026-10-08, independently of npm versions. - Restart hosts after CLI or package changes; loaded resources are not hot-reloaded.
- Keep exact Workflow resources for unfinished checkpoints.
- Test the actual provider and model's Tools, output Schema, and output-budget behavior.
- Validate business check commands against the host's executable versions. The obsolete
--experimental-transform-typesflag is not accepted by Node 26. - Separate native-form UI validation from successful MCP Tool transport.
For the diagnostic sequence, use Logs and diagnostics. For interrupted work, use Recovery.