Agent safety — 2.30.0

No hidden prompt can
hold the shell hostage.

Agent safety means no hidden prompt can hold the shell hostage. xops separates plan from execute, supports explicit --yes, and returns deterministic exit codes for approval-required work instead of waiting on stdin. See Agents.

  • Plan separate from execute--plan --json resolves intent to a command without running it.
  • Deterministic refusal, not a hangApproval-required work exits 4 in non-TTY, CI=true, XOPS_AGENT=1, or --agent contexts.

Stack releases can keep local file: development links while publishing registry-safe packages. With syncInternalDepsOnPublish, xops rewrites in-stack local deps to the published registry version for publish, installs, publishes, and restores the local specs afterward.

  • Registry-safe publish, local dev unchangedfile:../jobs-db becomes ^<publishedVersion> only for the downstream publish step.
  • Opt-in, scoped to the stackOnly in-stack internal deps are rewritten when a stack sets syncInternalDepsOnPublish: true — not every file: dependency.

How it works

Five checks before
a single package ships.

The publish path in xops is a gauntlet, not a formality. Every step must pass before the real npm publish command is called.

  • Validates .gitignore and .npmignore Creates .npmignore if absent. Confirms rules are consistent with .gitignore and safe to publish.
  • Dry-run pack inspection Runs npm pack --dry-run --json and inspects every file that would be included in the package.
  • Blocks sensitive file patterns .env files, secrets, keys, credentials — detected before they can ship. Publish is blocked until the issue is resolved.
  • Post-bump re-validation After bumping the version, the pack check runs again on the exact final state. The check is not skipped because it already passed once.
  • Retry-aware publish verification (2.29.1+) After npm publish succeeds, xops checks the registry for the new version and retries while npm replication lag catches up, instead of failing the run and skipping git push. If npm reports the version was already published, xops verifies it and continues.
Safety is not a flag. It is the default route to publish.
blocked publish
$ xops --publish ✕ Publish blocked .env.production would be included in the npm package. Fix: add .env* to .npmignore rerun xops --publish
clean publish
$ xops --publish ✓ .npmignore validated ✓ Pack check passed (14 files) ✓ No sensitive files found ✓ Bumped 1.2.3 → 1.3.0 ✓ Pack check passed again ✓ Published @scope/core@1.3.0

Guarantee

What xops guarantees.
And what it doesn't claim.

Guaranteed by the publish flow

  • No publish without a passing pack checkThe dry-run check is not optional and cannot be skipped in the default flow.
  • No publish if sensitive patterns are detectedThe block is hard. You fix the ignore rules, then run again.
  • Post-bump check on the final stateThe version bump happens first; the check runs on what will actually ship.
  • Scoped fix policyDefault --fix refreshes in-house @x12i/* / @exellix/* only; public toolchain bumps require --fix-public.
  • Engine guardrailsBlocks upgrades when installed packages require a newer Node runtime; xops validate --build catches broken installs.
  • Publish is complete only after verificationnpm accepting the publish is not enough — xops confirms the version is visible on the registry, retrying through normal replication lag before deciding the run failed.

What xops does not claim

  • It does not audit the contents of your published files for correctness, only for unwanted inclusions.
  • It does not scan for hardcoded secrets inside your source files — only files that would be packed.
  • It cannot undo a publish — that is an irreversible external effect, logged with full details.
  • Publish verification retries, it does not guarantee success — if npm never shows the version after the retry window, the run still reports a failure.

Setup safety — in progress

Installing tools
is also an operation.

xops recommendations are read-only. But when a developer approves, xops can apply a setup plan: install a dev dependency, add a script, write a config file, create a CI job, or initialize a supported local tool.

That setup path is safety-controlled like release. Before anything changes, xops shows the exact plan — see Apply.

xops can speed up setup, but it never hides setup.