{
  "markdown": "<p align=\"center\">\n  <picture>\n    <source media=\"(prefers-color-scheme: dark)\" srcset=\"assets/logo-dark.svg\">\n    <img src=\"assets/logo.svg\" width=\"180\" alt=\"hush\">\n  </picture>\n</p>\n\n<p align=\"center\"><em>a secret store for AI agents, the one with no <code>get</code>.</em></p>\n\n<p align=\"center\">\n  <a href=\"https://github.com/royashbrook/hush/actions/workflows/ci.yml\"><img src=\"https://github.com/royashbrook/hush/actions/workflows/ci.yml/badge.svg\" alt=\"CI\"></a>\n  <img src=\"https://img.shields.io/badge/license-MIT-1f3a34?style=flat-square\" alt=\"MIT\">\n  <img src=\"https://img.shields.io/badge/runs%20on-mac%20%C2%B7%20linux%20%C2%B7%20windows-1f3a34?style=flat-square\" alt=\"cross-platform\">\n  <img src=\"https://img.shields.io/badge/get-none-1f3a34?style=flat-square\" alt=\"no get\">\n</p>\n\n<p align=\"center\"><strong>get a secret once into the OS keychain, then inject it into commands forever, the value never hits stdout, the transcript, or the cloud.</strong></p>\n\n---\n\nA secret store for AI agents, with one hard rule: **the agent never sees the plaintext.**\n\nValues never reach stdout, so they never land in the tool result, the transcript, or the cloud. A\nsecret only ever moves from the store straight into the consumer. There's no `get` on purpose, a\nplain getter is the leak.\n\nThe point: you (an agent) are running as the user with their CLIs already authed, so you can already\nset a server-side secret or call a service, you just can't *see* the value without it landing in the\nchat. hush gets it once into the OS keychain, then you inject it into those commands forever. No\nchat paste, no temp files, no `.env` to commit by accident.\n\n## agents: start here\n\n**If you were handed this repo's url, install yourself, then follow the playbook.** Get the `hush`\nscript onto the box and read [`SKILL.md`](SKILL.md), that's the whole onboarding (it covers store /\nmint / inject and how to adopt hush in the repo you're working in). The script is one self-contained\nbash file; put it wherever your agent loads tools or just on your `PATH`:\n\n```sh\ngit clone https://github.com/royashbrook/hush\nchmod +x hush/hush\n# then put hush/hush on your PATH, or move it into your agent's skills/tools dir\n```\n\nor run it straight from npm without cloning: `npx @royashbrook/hush <cmd>` (mac/linux; on windows use the\nclone, the orchestrator is bash).\n\nClaude Code convenience (auto-loads as a skill): clone straight into the skills dir instead, whole\nsession `git clone https://github.com/royashbrook/hush ~/.claude/skills/hush`, or one project\n`./.claude/skills/hush`. Other agents: see [AGENTS.md](AGENTS.md).\n\nThat's it, the human points you here and says \"use the hush skill,\" and you take it from here. The\none thing only a human can do is paste a secret they hold: when you hit that, run `hush set <name>`\nand a hidden dialog pops on *their* screen (you never see the value).\n\n## install (humans)\n\nSame clone as above, or just grab the single `hush` script and put it on your PATH.\n\nBackends: macOS Keychain, Linux libsecret (`secret-tool`), and Windows DPAPI (via PowerShell) are\nbuilt in. On other platforms keep the same contract with your OS secret store (see [SKILL.md](SKILL.md)).\nCross-OS tested in CI (manual `workflow_dispatch`, all three runners).\n\n## quick start\n\n```sh\nhush set my-vendor-token                      # paste a value you hold (hidden prompt)\nprintf '%s' \"$TOK\" | hush set my-vendor-token # ...or pipe it in (scripts/CI), still off argv\nhush set my-vendor-token --gui                # force the dialog (or --tty / --pipe; HUSH_PROMPT= too)\nhush mint app-operator-key                    # generate + store a random one\nhush run TOKEN=my-vendor-token -- some-cmd    # inject into a command, never printed\nhush sync lastpass --dry-run                  # preview a one-way LastPass sync\nhush sync lastpass                            # upsert every name under LastPass group \"hush\"\nhush sync keepass --database vault.kdbx --db-secret keepass-password --dry-run\nhush sync bitwarden --dry-run                 # requires an unlocked BW_SESSION\nhush list                                     # names only, never values\n```\n\n**On an agent host where the dialog won't open** (some runners have no GUI session, so macOS can't\npost the paste dialog, `Connection Invalid ... hiservices-xpcservice`): hush now says so plainly\ninstead of a misleading \"cancelled or empty\", and the fix is to **pipe the value**\n(`printf '%s' \"$VAL\" | hush set <name>`) or run `hush set <name>` from a GUI-attached Terminal.\n\nNaming: keep the default `hush` namespace and **prefix names by project** (`blame-cf-token`,\n`lifescored-gemini-key`) so one keychain search for `hush` finds everything. `HUSH_NS` is only for a\ngenuinely separate store, not per-project. Need to fix an existing name? `hush rename <old> <new>`\nmoves the value internally (never re-asked, never printed). Full docs + the portable contract:\n[SKILL.md](SKILL.md).\n\n## sync to LastPass\n\nInstall and log into the official LastPass CLI once, then preview and run the sync:\n\n```sh\nbrew install lastpass-cli                     # macOS\nlpass login you@example.com\nhush sync lastpass --dry-run                  # names + destinations only, no values fetched\nhush sync lastpass                            # all names -> hush/<name>\nhush sync lastpass --group team/secrets api-key deploy-key\nhush sync lastpass --exclude local-only       # repeat to keep local-only names out of bulk sync\n```\n\nThis is an upsert into each LastPass entry's password field. A missing entry is created, a unique\nentry is updated, and duplicate LastPass names fail closed. Values move over stdin, never argv,\nstdout, or a temp file. Each write uses `--sync=now`, so hush reports success only after LastPass has\nsynchronized it to the server. Multiline hush values are refused because `lpass` password-field\nedits accept one line and would otherwise truncate them.\n\nThe sync runs wherever both hush and the official `lpass` CLI run: macOS, Linux, and Cygwin. The\nofficial CLI does not currently provide a native PowerShell or Node entry point, so native Windows\nremains limited by that dependency rather than by the hush store backend.\n\n### schedule it with experimental auto-login (macOS)\n\nA cold npm install includes an optional Node-based launchd helper:\n\n```sh\nnpm install -g @royashbrook/hush\nbrew install lastpass-cli\nhush-lastpass-schedule install --auto-login --email you@example.com --every 6h\nhush-lastpass-schedule status\n```\n\nAuto-login is experimental. Its complete contract passes deterministic fake-CLI tests, but we could\nnot complete a real trusted login because Homebrew `lastpass-cli` crashed in its MFA path before any\nvault access. This matches upstream [`lastpass-cli` issue\n#719](https://github.com/lastpass/lastpass-cli/issues/719). It may work with account/MFA combinations\nunaffected by that bug, but it is not live-tested.\n\nThe design performs one interactive `lpass login --trust`, then asks once for the LastPass master\npassword through hush's hidden prompt. Scheduled runs are intended to use that local Keychain value\nto restore the `lpass` session after reboot. This is explicit opt-in: no LastPass login material is\nstored unless `--auto-login` is present. The helper never uses `lpass --plaintext-key`, and its\ndedicated login secret is always excluded from vault sync. Failed setup installs nothing; revoked or\nexpired trust makes later jobs fail closed.\n\nUse `hush-lastpass-schedule remove` to unload the job. It retains the non-secret config and the hush\nlogin secret so removal cannot silently destroy credentials. Delete that secret separately with\n`hush rm hush-lastpass-master-password` if you want to revoke the opt-in completely.\n\nAn API key cannot replace this login: the published [LastPass Business\nAPI](https://developer.lastpass.com/business/docs/index.md) manages accounts, companies, and\nreports, but does not expose vault-item writes. The scheduler is Node so other native schedulers can\nbe added without changing the sync contract, but this release installs launchd on macOS only.\n\nAll three macOS sync schedulers use local-time calendar slots, so\n[launchd runs a slot missed during sleep when the Mac wakes](https://developer.apple.com/library/archive/documentation/MacOSX/Conceptual/BPSystemStartup/Chapters/ScheduledJobs.html).\n`--every` is the maximum cadence; unusual values that do not divide a day or week evenly may run\nslightly early at the boundary, never later.\n\n## sync to a local KeePass database\n\n[KeePassXC](https://keepassxc.org/) opens the same encrypted KDBX file on macOS, Linux, and Windows.\nPut that file in an iCloud Drive folder and it becomes an offline-first backup that another iCloud\nmachine can open without a service login:\n\n```sh\nbrew install --cask keepassxc\nhush set hush-keepass-master-password\nhush sync keepass --database \"$HOME/Library/Mobile Documents/com~apple~CloudDocs/hush/hush.kdbx\" \\\n  --db-secret hush-keepass-master-password --init\n```\n\n`--init` refuses to overwrite a file. Later runs omit it and upsert entries in group `hush`:\n\n```sh\nhush sync keepass --database \"$HOME/Library/Mobile Documents/com~apple~CloudDocs/hush/hush.kdbx\" \\\n  --db-secret hush-keepass-master-password --dry-run\nhush sync keepass --database \"$HOME/Library/Mobile Documents/com~apple~CloudDocs/hush/hush.kdbx\" \\\n  --db-secret hush-keepass-master-password --exclude local-only\n```\n\nThe database password and entry passwords reach `keepassxc-cli` only over stdin. They are never put\non argv, stdout, logs, or a temp plaintext file. The database-password secret is always excluded.\nMissing entries are created, unique entries are updated, duplicate names fail closed, and multiline\nvalues are refused rather than truncated.\n\n### schedule it into iCloud (macOS)\n\nThe npm package includes a Node/launchd helper. A cold setup creates the database if absent, asks for\nits password through hush when needed, performs the first sync, and loads the recurring job:\n\n```sh\nnpm install -g @royashbrook/hush\nbrew install --cask keepassxc\nhush-keepass-schedule install --every 6h\nhush-keepass-schedule status\n```\n\nThe default destination is `iCloud Drive/hush/hush.kdbx`. Scheduled runs update an encrypted local\nmirror under `Application Support/hush`, then atomically publish a completed copy. KeePassXC never\nopens CloudDocs from launchd, avoiding macOS's headless iCloud privacy block. A publish that takes\nmore than 30 seconds fails with an actionable error instead of hanging. Use `--database`,\n`--db-secret`, `--group`, repeatable `--exclude`, or positional names to narrow it. `remove` unloads\nthe LaunchAgent but keeps the destination, local mirror, and mode-0600 metadata config.\n\nKeep one durable copy of the database password outside this KDBX. After a machine loss, the iCloud\nfile cannot recover the hush secret that unlocks it. Treat one machine as the writer while iCloud is\nsyncing to avoid conflicted KDBX copies.\n\n## sync to Bitwarden\n\nThe official [Bitwarden CLI](https://bitwarden.com/help/cli/) supports create and edit operations,\nAPI-key login, and session-based vault access. Install it, then keep the three required credentials\nin hush:\n\n~~~sh\nbrew install bitwarden-cli\nhush set bitwarden-client-id\nhush set bitwarden-client-secret\nhush set bitwarden-master-password\n~~~\n\nBitwarden's personal API key authenticates the CLI, but [does not replace the master\npassword](https://bitwarden.com/help/personal-api-key/). Vault reads and writes still require an\nunlock session. The npm-shipped scheduler handles that lifecycle without repeated interaction:\n\n~~~sh\nhush-bitwarden-schedule install --every 6h\nhush-bitwarden-schedule status\n~~~\n\nInstall verifies all three hush names, performs bw login --apikey when needed, unlocks with\n--passwordenv, runs a value-free dry-run, then installs launchd. Each scheduled run obtains a\nshort-lived session, syncs, and locks the CLI. API credentials, the master password, and the session\nare absent from argv, logs, the plist, and the mode-0600 metadata config.\n\nThe underlying command can also be used inside any already-unlocked Bitwarden CLI session:\n\n~~~sh\nhush sync bitwarden --dry-run\nhush sync bitwarden                         # all non-auth secrets -> folder hush\nhush sync bitwarden --folder backups api-key deploy-key\nhush sync bitwarden --exclude local-only\n~~~\n\nMissing login items are created and unique items are updated. Exact duplicate names in the target\nfolder fail closed. Existing item JSON flows directly from bw into the JSON transformer, and encoded\ncreate/edit bodies flow directly into bw over stdin. Passwords never enter argv, stdout, logs, or\ntemp files. The three default Bitwarden auth secrets are always excluded. Bitwarden automatically\npushes successful create and edit changes to the server.\n\nThe core sync is Bash plus Node and follows the platforms supported by hush and bw. The included\nscheduler currently installs a macOS LaunchAgent. hush-bitwarden-schedule remove unloads it while\nretaining the non-secret config and hush credentials.\n\n## not a vault\n\nAn agent with shell access can read+write this store, so it's not a lock against a hostile process.\nIt's structure that keeps plaintext out of the transcript and makes \"store once, inject everywhere\"\nthe easy path. It's also only as durable as the machine it's on (a local keychain), back the machine\nup, or sync onward into a real secret manager, and don't make hush the only copy of a secret you\ncan't regenerate. MIT licensed.\n",
  "bytes": 13473,
  "sha": "384fd56dd31591d5efdd0e5ff61159c85d094b11975ee63b6722b11314528163",
  "repo_slug": "royashbrook/hush",
  "fonte": "repo",
  "truncated": false,
  "api": "https://agentalog.com/api/listings/mcp_com_royashbrook_hush_59e6473c/readme"
}