API Key Case

API Key Case

Keep building with your AI coding agent without pasting API keys into chat. Enter values in a dedicated window and keep them in your OS secret store. Claude Code, Codex, Cursor, or a similar agent can check registration status and configure supported Cloudflare, Vercel, or GitHub destinations. Deployment is a Pro feature. The tool returns status to the agent, never the key value.

日本語版のREADMEは [README.ja.md](https://github.com/melavern/api-key-case/blob/main/README.ja.md) にあります。

Instructions for v1.0.0. Start with the generic Windows workflow. Check npm for published versions.

This tool reduces accidental exposure risk. It does not guarantee complete secret protection. Always review generated files before sharing them.

完全な安全は保証しない。事故確率を下げるツールです。生成物はAIや外部サービスへ渡す前に必ずご自身で確認してください。

[Website](https://apikeycase.melavern.com/) · [OS support status](https://apikeycase.melavern.com/os-support) · [npm](https://www.npmjs.com/package/api-key-case) · [Changelog](CHANGELOG.md) · [Security](SECURITY.md) · [Support](SUPPORT.md) · [Terms](https://apikeycase.melavern.com/terms) · [Privacy](https://apikeycase.melavern.com/privacy) · [Brand and third-party notices](NOTICE)

Quick start

The normal Agent-first support baseline is Windows 11 with Windows Hello. macOS is a collaborative verification edition: its implementation, current CI and real Keychain evidence exist, while native GUI approval, Accessibility resistance, Intel hardware and real-Mac provider deployment remain unverified. macOS verification is still in progress; do not purchase Pro relying on macOS deploy. See the OS support status and the macOS verification plan.

Requires Node.js 20 or later on Windows, macOS, or Linux. On Windows, high-risk approval, remove, and trust forget in v0.9.1 require Windows 11 build 22000 or later and Windows Hello (PIN, fingerprint, or face) set up for that account; Windows 10 and accounts without Hello fail closed for those decisions and hand off to a human instead, while scan, vault, and Secret input remain available. Because deploy is the paid feature, check that before buying. Linux supports local diagnosis, status/history, and human-owned-terminal storage when an OS store is available; Agent-first input, approval, executing deploy, and approval-required value/trust removal are not provided. Linux keyring backend selection and login/reboot persistence remain environment-dependent.

Generic Windows workflow

In v1.0.0, a supported Windows session can:

• Reuse a registered key in another project or development environment selected by its owner.
• Start an approved Node.js / Python development app with registered keys.
• Check interrupted registration, placement, and launch results before continuing.

The new workflow targets Windows. Placement and app launch require Pro and fresh human identity verification. Approved apps and their dependencies can read their keys; review the app before approving it. Ask your usual agent to run npx -y api-key-case@0.10.0 agent-init . and follow the returned protocol. It checks capabilities and existing project registrations before requesting missing input. The common input window uses a task-specific key name; classification and context are under Details.

The published release's basic commands can be tried independently:

# Scan the current project locally. Real .env contents are not read.

npx -y api-key-case@latest scan .

Generate redacted context for an AI coding agent.

npx -y api-key-case@latest scan . --agent-report

Save a value through a hidden interactive prompt.

npx -y api-key-case@latest save OPENAI_API_KEY

Check status only. The value is never returned.

npx -y api-key-case@latest check OPENAI_API_KEY

Never put a real secret in a command argument, Issue, chat message, or generated report. Human-owned terminal use keeps the hidden prompt; Agent-first use must request save --ask and enter the value only in the Human Plane dialog.

Start with your current .env

You can register keys you already use without letting the Agent read .env. Confirm only the Secret name, open the file yourself, and copy only its value into the Human Plane. This is not automatic ingestion: API Key Case does not delete, synchronize, replace, or otherwise change the original .env, so you can keep using it where needed. Registration can be the end of the task; deploy is separate.

The scanner currently recognizes .env.example plus common JavaScript/TypeScript references. A missed name in another language or unsupported syntax does not mean the Secret is unnecessary: if you know its name, you can still save or check it directly. The legacy save/check commands keep one value per project/name. The generic workflow below uses separately registered keys and explicit associations, so distinct purposes can use distinct keys without overwriting one another.

Deployment has additional provider/project constraints. In particular, Cloudflare Agent-first deploy stops under API Key Case's safety conditions when a Wrangler project also has a real .env, .env.* (excluding .env.example), .dev.vars, or .dev.vars.* file, because Wrangler can load those files. This is not a login or Free-plan failure: local Secret registration remains available, and API Key Case does not modify the file. Run the Free readiness diagnosis before purchasing Pro.

Agent-first Control and Human Planes (Phase A/B/C/D/E)

The following commands require v0.9.2. Confirm npx -y api-key-case@0.9.2 --version resolves to 0.9.2 before use. Until npm lists that exact version, use an installed candidate tarball as described in candidate testing.

api-key-case agent-init .          # print the session protocol and manage existing host instructions

api-key-case agent-init . --check # no-write drift/symlink safety check api-key-case agent-init . --host agents # explicitly create AGENTS.md in a fresh project api-key-case next --json . # closed semantic status and nextActions api-key-case save OPENAI_API_KEY --ask # separate Windows/macOS Human Plane api-key-case history --json . # Free: past deploy results, never current values

agent-init preserves content outside its managed block, writes only inside the project, rejects symlinks/junctions, and does not edit global or MCP configuration. Persistent instructions pin the exact version that runs agent-init (for example, api-key-case@0.9.2), never @latest or a floating major line; this prevents a later pre-stable minor release from changing an existing repository's Agent protocol without an explicit agent-init rerun.

next --json returns closed enums and names/status only. It has no command, argv, or free-form execution field, and never includes a secret value, partial value, value-derived hash, or value length. For actor: "human", kind: "register-secret", the exact-version Agent protocol requests save --ask; the value is entered only in the separate Human Plane and only status returns to the Agent side.

Schema 2 adds Free readiness and a project setup summary for your existing Coding Agent to explain in your language. setup.stage and setup.counts show what is registered, what is missing, and what needs attention. host describes input/approval requirements; each target's readiness checks its environments using the same trusted CLI/configuration rules as executing deploy, without placing a Secret or opening a dialog. Environmental blockers are separate from license.plan: purchasing Pro cannot fix an unsupported host. prerequisites-checked still leaves human interaction and provider write permission unverified; deploy always rechecks its own boundaries. Local registration is not remote deployment: setup.deploymentState remains not-inspected.

The Agent groups missing names, opens existing input dialogs sequentially, prepares the requested destination, and summarizes actual operation results. Cancellation or failure stops the group; it does not create a reusable or batch approval. Provider login, key issuance, purchase/license activation and OS verification remain human prerequisites. For a fresh repository, the current Agent can explicitly use agent-init --host agents, --host claude, or --host cursor; this creates only that host's project instructions with the same path/drift checks. Without --host, only existing host markers are used. See the setup contract.

Each target in next --json also carries a deployment block: automatic lists the environments an agent may deploy to right now with no human interaction, humanApproval lists the rest, and destinationTrust reports whether this project's destination is trusted, unconfirmed, changed, unresolved, or not-applicable. An unconfirmed or changed destination adds an actor: "human", kind: "approve-deploy-destination" action. The agent relays it; it can never satisfy it.

Phase B Secret input and Phase C high-risk approval use separate OS dialogs on Windows and macOS. On Windows 11 build 22000+ with Windows Hello set up, the plan dialog's Yes/Delete button only starts IUserConsentVerifierInterop::RequestVerificationForWindowAsync; only the OS result Verified approves, and every other result fails closed. Linux, Windows 10, accounts without Hello, headless sessions, and hosts where the fixed system helper cannot be verified hand off instead. There is no Agent-owned PTY fallback. Production, GitHub, Vercel development (provider-readable), destructive/overwrite-capable operations, and other high-risk plans require this boundary. Phase C binds the verified decision to one in-process execution snapshot.

Phase D adds the destination side of that boundary. Every deploy that actually runs is bound to one Destination Identity — the fixed project realpath, target, environment, destination-selecting repository config, and the provider account identity resolved through the same trusted CLI and sanitized environment. A human confirming an operation once records that identity in the OS secret store; a first use or any change to it goes back through the Human Plane. Only Vercel preview on a confirmed destination, in project scope and without --force, can then repeat without asking again.

Past deployment results

On a new chat or resumed deployment task, the Agent also reads history --json. It reports past completed, incomplete or unknown operations. A failed --force may already have changed the provider; interrupted or unsaved results remain unknown. A later registration timestamp flags an update, but matching timestamps and destination selection never prove the current value is the same. History supplies no approval, trust, automatic retry or automatic redeployment.

The local metadata file at ~/.api-key-case/deployment-history/ retains the last 200 attempts per project. It contains names, scopes, target/environment, destination-only identifiers and operation timestamps/results; no values, partial values, value hashes/lengths or provider output. When no deploy is running, you can explicitly delete that directory (or one project subdirectory) to discard history; stored values and destination trust are separate. Missing or unreadable history is unknown. A start