jit moves developer secrets into a Touch ID vault on macOS

A Show HN post introduces jit, a macOS command-line tool built around one specific problem: on a typical developer machine, secrets sit in plaintext everywhere, .env files, ~/.aws/credentials, ~/.zshrc exports, .npmrc tokens, MCP server configs, and anything running under the same user account can read them. The documentation names three concrete threats: a bad curl-to-shell install script, a sketchy npm install, and AI coding agents now running inside editors with the developer's own full permissions.

jit's fix is to move each secret into a local encrypted vault unlocked by Touch ID, then rewrite the original file so whatever normally reads it keeps working. What remains on disk at the old location is a decoy; the real credential value is decrypted only in memory, only for the specific process that requested it, and only after a biometric prompt. jit is also designed never to delete a credential outright: migrating one moves its value into the vault and leaves a working hook behind, such as a decoy .env file.

On Apple Silicon, installation is one Homebrew command, or a curl-and-tar download of the signed binary; an Intel Mac has no prebuilt binary and must be built from source with Go. Releases are signed with a Developer ID and notarized by Apple, so neither install path triggers a Gatekeeper prompt, and jit doctor, a built-in diagnostic command, reports the signing identity, CZC6BH93GJ, so a user can verify what actually landed on their machine rather than take the project's word for it. Upgrading, through Homebrew or jit upgrade, checks that same signature and a checksum before swapping the binary and restarting the background service; the vault itself is left untouched by an upgrade.

Day to day, jit scan is a read-only command that inventories what is exposed without changing anything. The documentation's own worked example shows a machine starting at seven secrets found and zero percent protected, where a single jit migrate command would bring five of those secrets, spread across four files, under vault protection, accounting for 71% of the total; the remaining two secrets, illustrated by a production database password found in two files, are marked fixable only by the user, by rotating the password and deleting every copy, not by jit, accounting for the other 29%. jit migrate covers AWS and Terraform credentials, Google Cloud's application-default credentials, Docker registry logins, the shell exports sitting in a user's .zshrc file, and secrets already recorded in shell history. A separate jit wrap command is a one-time step for command-line tools that carry their own login token, such as gh, stripe, or glab, after which the tool is used exactly as before. For anything else, the everyday pattern is jit run, which injects the real secret value into that one process only.

Two separate Touch ID prompts guard access. The first unlocks the vault itself: one fingerprint opens it for a session that re-locks after five minutes without activity and never stays open past eight hours in total, no matter how continuously it is used. The second prompt is per tool: the first time a given tool asks for a specific credential, jit asks and names what is asking, so a sketchy npm install reaching for the same AWS keys a developer just used still has to ask, and can be refused, even while the vault is unlocked. Repeated calls from the same tool in the same session do not prompt again, but a different tool asking for the same credential, for instance Terraform reading the same AWS credential right after the AWS CLI did, triggers its own separate prompt. The command jit service consent off switches off this per-tool gate while leaving the vault lock itself in place, and switching it back on, or off, itself requires a Touch ID. jit run --trust lets a single run approve every tool it needs in one gesture instead of prompting per tool.

For work that has to run unattended, the documentation's own example is an AI coding agent left running overnight, jit adds process grants. One worked example, jit grant --process claude --profile jamf --for 8h, uses a single Touch ID to let a named terminal's entire process tree use specific secrets without further prompts, for a duration the user sets at grant time; this example sets it to eight hours, though the documentation does not state any default or maximum duration for a grant in general. The process name in the example, claude, is the documentation's own stand-in for an AI coding agent in this scenario, not a claim about any specific vendor's product. The grant survives screen lock and covers anything that terminal launches later, including a script that fires overnight, but a program that merely shares the same process name, launched elsewhere on the machine, does not inherit it. A grant ends at its own deadline, when the terminal is closed, or immediately on jit grant revoke, which needs no fingerprint to run, since removing access is treated as always safe. A separate --pid option scopes a grant to one specific process instead of an entire terminal's tree, ending when that process exits.

Every command and every credential access is written to a durable, append-only log, read back with jit audit, newest event first, one line per event in a compact key-value format; command arguments are masked, so a log line can prove a given command ran without the log ever having stored the secret it carried. The documentation's own sample output shows a credential read by an aws s3 ls command logged together with its parent process, and a separate entry recording a denied credential request from a Node.js post-install script running under npm. The log can be filtered by event kind, status, a time window, parent process, secret name, user, or a text search, streamed live with a follow flag, or exported as JSON.

The documentation lists a broad set of supported credential types: .env files, shell exports, AWS and Terraform credentials, kubeconfig, Docker registry logins, Google Cloud's application-default credentials, .npmrc and .netrc token files, MCP server configs, bare token files, secrets already sitting in shell history, wrappable command-line tools such as gh, stripe, and vercel, and SSO tools that mint credentials at login, such as clisso; anything not on that list can still be wrapped by hand with jit wrap add. The project's own status line is explicit: jit today is macOS-only, Apple Silicon only, and still in development. The documentation gives no pricing, license, funding, or company information, and does not name an individual author or say when the project began; it is identified only by its GitHub organization, jitpass. At the time this Show HN post was captured, the discussion had drawn 16 points and 10 comments.

Key facts

• jit is a macOS command-line tool, Apple Silicon only today, with Intel Macs needing a from-source build, that moves plaintext secrets, .env files, AWS credentials, .npmrc tokens, MCP configs, and more, into a local vault unlocked by Touch ID.
• It rewrites the original files with working decoys, so tools like the AWS CLI, Terraform, and Docker keep working while the real credential value is decrypted only in memory for the one process that requested it.
• Two separate Touch ID prompts gate access: one unlocks the vault for a session that re-locks after five minutes without activity and never stays open past eight hours total, and a second asks by name the first time a given tool requests a specific credential.
• A process-grant command lets a named terminal's process tree use specific secrets unattended for a set duration, the documentation's own worked example grants eight hours, covering anything that terminal launches later, including an overnight script; revoking a grant needs no fingerprint.
• Every command and credential access is written to a durable, greppable audit log with command arguments masked, so a log entry can prove a command ran without ever storing the secret it carried.

Why it matters

The specific threat this targets is current: developer workflows now routinely involve processes acting with the developer's own permissions that the developer did not directly invoke, a curl-to-shell installer, an npm install script, or an AI coding agent running inside an editor, and any of them can read a .env file or an AWS credentials file exactly as easily as the developer can. jit's answer is narrow and mechanical rather than a broad identity platform: decrypt a secret in memory only, only for the process that asked, only after a biometric or an explicit per-tool consent. It is also, by its own account, an early project. The status line reads 'macOS-only (Apple Silicon), and still in development', and the Show HN discussion had drawn just 16 points and 10 comments at the time this was captured, so this is a narrowly scoped, early-stage tool rather than an established product with a track record.

Who it affects

Directly, developers on Apple Silicon Macs who keep credentials in the usual plaintext places: .env files, shell profile exports, AWS and Google Cloud credentials, Docker registry logins, and CLIs like gh, stripe, or clisso that mint their own login tokens. Anyone on Windows or Linux gets nothing from this release, and an Intel Mac user gets nothing prebuilt either; the documentation states only that jit is macOS-only today and does not say whether Windows or Linux support is planned. The process-grant mechanism is aimed specifically at people running AI coding agents or other unattended jobs locally overnight or through screen lock, which is also the documentation's own worked example for that feature.

How to use it

Installation on Apple Silicon is one Homebrew command, or a signed binary fetched with curl and unpacked with tar; on an Intel Mac, there is no prebuilt binary, and building from source with Go is the only route. jit doctor checks the install and reports the binary's signing identity, so a user can confirm what actually landed on their machine. Core day-to-day use is jit scan, read-only, to see what is exposed; jit migrate, with a --dry-run preview or a specific path to scope it to one project, to move secrets into the vault; and running ordinary commands through jit run so the real value reaches only that one process. Command-line tools that carry their own login token, such as gh or stripe, need a one-time jit wrap instead. The documentation gives no pricing, license, funding, or company information anywhere.

How solid is it

The strongest concrete trust signal is technical: releases are cryptographically signed with a Developer ID and notarized by Apple, jit doctor lets a user verify the exact signing identity rather than trust the install blindly, and both Homebrew and jit's own upgrade path re-check that signature and a checksum before ever swapping the running binary. Beyond that, there is little to independently verify. The project names no individual author, founder, or company beyond its GitHub organization, jitpass, does not say when development started, and the protection percentages shown in the documentation, 0%, 71%, 29%, are a worked illustration of the tool's own output, not a measured result across real installations. The project's own status line already flags it as still in development, and the Show HN thread it arrived on was a modest one, 16 points and 10 comments.

Risks and caveats

The tool runs only on Apple Silicon Macs today; Intel Mac users must build it from source, and the documentation says nothing about Windows or Linux support being planned. jit is explicit that it never deletes a credential outright, migrating one only moves its value into the vault and leaves a working hook in its place, so a credential that was already compromised, the documentation's own example is a leaked production database password, still needs the user to rotate it and delete every copy; jit will not do that step. A process grant, once made, hands out unattended access for its full duration, set by the user, to anything later launched from that same terminal, which is a wide blast radius if that terminal session itself is compromised while the grant is active. And because the documentation gives no information on funding, company backing, or how long the project has existed, there is currently no way to judge its long-term maintenance beyond the signed-release mechanics themselves.

“Your secrets live in plaintext all over your machine: .env files, ~/.aws/credentials, ~/.zshrc exports, .npmrc tokens, MCP configs.”

— jit's documentation