Skip to content

zn-gate 1.9.0

Choose a tag to compare

View all tags
@github-actions github-actions released this 16 Oct 08:25
· 263 commits to main since this release
v1.9.0
0d78201

zn-gate 1.9.0 makes npx -y zn-gate init the one command that sets up zn for the coding agents on your machine, and adds zn-gate check to show that zn stops your agent from reading a secret. Block messages for commands only you may run now give the exact command. Update with npm install -g zn-gate@1.9.0; the Python package has no code changes and moves to 1.9.0 to keep the versions in step.

Breaking for scripts: zn-gate init without options no longer wraps the MCP servers in your agent configs. Use zn-gate init --wrap-mcp.

Added

  • zn-gate init is now a guided setup: it finds Claude Code, Codex CLI, Cursor and OpenCode, shows the one route that protects each agent that is not protected yet (the zn-gate plugin for Claude Code, zn hooks install for the others, from a global install rather than the npx cache), runs each step after you confirm it in your own terminal, and ends with zn-gate check. When an AI agent or a script runs it, it only prints the steps.
  • zn-gate check (also zn-gate doctor) shows that zn stops your coding agent from reading a secret. For each agent set up for your user (Claude Code through the zn-gate plugin or zn hooks install, Codex CLI, Cursor, OpenCode), it asks zn's hook to let the agent read a .env file with a fake key and an ordinary file, in a temporary folder. An agent counts as protected only when the first is blocked and the second allowed. For Claude Code, Codex CLI and Cursor it also runs the installed hook, which finds a hook that cannot start or that blocks every file (on Windows, hooks installed as zn hook <agent> are checked against zn's rules instead, and the output says so). It says how to fix an agent that is not protected. Nothing is sent over the network and no setting changes. See docs/check.md.
  • zn hooks install claude-code and zn-gate status warn when Claude Code settings stop zn from running: an organization policy that turns off all hooks (disableAllHooks), runs only its own hooks (allowManagedHooksOnly), or does not allow the secrets MCP server (managed-mcp.json, allowManagedMcpServersOnly, allowedMcpServers, deniedMcpServers), or disableAllHooks in your own settings. Claude Code does not show these. Only the settings files are read, not policy sent through claude.ai, MDM or the Windows registry.

Changed

  • The READMEs start with npx -y zn-gate init; the steps for each agent are under "Manual install".
  • Block messages, third batch: zn commands that only the user may run (hooks install and uninstall, unlock, lock, stats share on, secret, env shadow, pins approve, init) each say what the command does and the command for the user to run, with the agent, secret name or file name when the agent's command had one, instead of one message about secret values for all of them. Reading or changing ~/.zn now says how a command can still use a secret, and a secret after a shell keyword says why it cannot be filled in.
  • Breaking for scripts: zn-gate init without options no longer wraps the MCP servers in your agent configs: that is now zn-gate init --wrap-mcp. --dry-run, --shadow and --revert still select it. The guided zn-gate init runs only in your own terminal and asks before each step; zn's hooks also refuse the usual ways an AI agent would start it, as they refuse zn hooks install (the zn-gate plugin for Claude Code gets this rule once it is pinned to 1.9.0). --wrap-mcp is not affected.
  • CI: draft pull requests skip the test, package, plugin, Rust, Windows and action jobs until they are marked ready for review, and pushes that change only documentation skip the test and plugin workflows (Markdown in the packages and plugins still runs them); the plugin checks also skip documentation-only pull requests. On release pull requests, which are opened before the plugin can be pinned, a plugin pin one step behind the release is a warning in Public facts; it still fails on main and next, so main stays red after a release merge until the plugin is pinned. The Plugin repository workflow ends with a warning instead of failing while the plugin repository's copy of its checks is out of date.
  • CI: pushes to next leave out the macOS jobs of the leak bench and the scrubber and vault tests, and run the plugin checks on macOS with Node.js 22 only; Ubuntu and Windows still run every version. The full matrix still runs on main, on pull requests into main and release branches, with the full-ci label and on manual runs. A new push to next cancels the CI runs still going for the previous one; runs on main always complete.
  • CI: the Rust build cache is saved only from main; next and pull requests restore it and save nothing, so the repository stays under its 10 GB Actions cache limit. A new weekly Cache cleanup workflow deletes the caches of closed pull requests and can be run by hand as a dry run.
  • The hash-pinned tool lists used by the CI and release workflows (.github/ci-test-requirements.txt, .github/release-requirements.txt) now say how to regenerate them with uv when a security alert names them, since Dependabot cannot update them.

How to verify these files: docs/verify-release.md

Assets 10
Loading