v1.20.0 adds a new Doppler secrets manager provider and fixes a bug where fnox sync would corrupt secrets that use json_path extraction.

Added

• Doppler secrets manager provider (#376) -- @natefaerber

fnox now supports Doppler as a secrets provider. The provider uses the Doppler CLI under the hood and supports project/config scoping, service token authentication, and efficient batch fetching via --json.

[providers]
app-prod = { type = "doppler", project = "my-app", config = "prd" }
app-dev = { type = "doppler", project = "my-app", config = "dev" }

[secrets]
PROD_DB_URL = { provider = "app-prod", value = "DATABASE_URL" }
DEV_DB_URL = { provider = "app-dev", value = "DATABASE_URL" }

All configuration fields (project, config, token) are optional -- when omitted, the provider falls back to the Doppler CLI's own defaults (from doppler setup or environment variables like DOPPLER_TOKEN). Authentication works via interactive login, service tokens in config, or the DOPPLER_TOKEN / FNOX_DOPPLER_TOKEN environment variables.

You can add a Doppler provider interactively with:

fnox provider add my-doppler doppler

See the full Doppler provider documentation for setup instructions, CI/CD examples, and multi-environment patterns.

Fixed

• fnox sync no longer corrupts secrets that use json_path (#371) -- @rpendleton

When syncing secrets that use json_path, the sync command was applying json_path extraction before caching the value. This meant the cached sync value contained only the extracted field (e.g. "admin") instead of the full raw secret (e.g. {"username":"admin","password":"secret123"}). On subsequent reads, json_path would be applied again to the already-extracted value, failing with "Failed to parse JSON secret".

The fix introduces SecretConfig::for_raw_resolve(), which strips post-processing fields (json_path, sync, default) before resolving. Both sync and reencrypt now use this method, ensuring raw provider values are always cached and future post-processing steps only need updating in one place.

New Contributors

• @natefaerber made their first contribution in #376
• @rpendleton made their first contribution in #371

Full Changelog: v1.19.0...v1.20.0

v1.19.0 adds a new fnox reencrypt command that makes it easy to re-encrypt all your secrets when encryption provider configuration changes -- for example, when adding or removing age recipients. This release also fixes a bug where fnox set -k would skip prompting for the secret value.

Added

fnox reencrypt subcommand (#365) -- @jdx

Previously, re-encrypting secrets after changing recipients required a tedious manual loop of fnox get and fnox set for each secret. The new fnox reencrypt command handles this in one step: it decrypts matching secrets and re-encrypts them with the current provider configuration, writing the updated ciphertext back to the correct source config file.

# Re-encrypt all age secrets
fnox reencrypt -p age

# Preview what would be re-encrypted
fnox reencrypt -p age --dry-run

# Re-encrypt specific keys
fnox reencrypt MY_SECRET OTHER_SECRET

# Filter by regex pattern
fnox reencrypt --filter "^DB_"

# Skip the confirmation prompt
fnox reencrypt -p age -f

The command correctly handles multi-line secrets, writes back to the original source file (including distinguishing root [secrets] from [profiles.X.secrets]), clears stale sync caches, and scrubs decrypted plaintext from the process environment after re-encryption. Only secrets backed by encryption-capable providers are eligible.

Fixed

fnox set -k now correctly prompts for the secret value (#367) -- @jdx

When using the -k / --key-name flag with fnox set, the command incorrectly treated it as a metadata-only operation and skipped prompting for the secret value. It also wrote the key name itself as the stored config value, bypassing the encryption provider entirely. Now -k works as expected: the secret value is read from stdin, a command-line argument, or an interactive prompt, and is properly encrypted and stored.

# These now work correctly
echo "my-secret" | fnox set -p age -k custom-key-name MY_SECRET
fnox set -p age -k custom-key-name MY_SECRET "my-secret"

Full Changelog: v1.18.0...v1.19.0

v1.18.0

v1.18.0 strengthens MCP server security with automatic output redaction and a secret allowlist, adds a --local-file option to fnox sync for keeping sync caches out of your committed config, and fixes auth prompt handling in batch providers. The YubiKey provider also no longer requires libusb to be installed just to start the binary.

Highlights

• MCP output redaction -- The exec tool now automatically replaces resolved secret values with [REDACTED] in stdout/stderr before returning output to the agent, closing a gap where agents could exfiltrate secrets via commands like printenv.
• MCP secret allowlist -- A new mcp.secrets config option restricts which secrets the MCP server exposes to AI agents, with dependency-aware warnings at startup.
• fnox sync --local-file -- Sync overrides can now be written to fnox.local.toml (gitignored) instead of the main config file, keeping your committed config clean.
• YubiKey dynamic libusb loading -- The binary no longer hard-links libusb, so it starts normally on systems without libusb installed. Users get a clear error with install instructions only when they actually use the YubiKey provider.

Added

• MCP exec output redaction (#357) -- @jdx
  The MCP exec tool now scans stdout/stderr for resolved secret values and replaces them with [REDACTED] before returning output to the agent. This prevents agents from exfiltrating secrets via commands like printenv or echo $SECRET. Redaction uses Aho-Corasick leftmost-longest matching for correctness and is enabled by default. To disable (not recommended):

  [mcp]
  redact_output = false
  

• MCP secret allowlist (#358) -- @jdx
  A new mcp.secrets config option restricts which secrets the MCP server resolves and exposes. Unlisted secrets are never resolved (avoiding unnecessary auth prompts) and are invisible to both get_secret and exec. At startup, fnox warns if the allowlist contains unknown names or if an allowlisted secret depends on another secret not in the list.

  [mcp]
  secrets = ["GITHUB_TOKEN", "NPM_TOKEN"] # only these are available to the agent
  

  When omitted, all profile secrets are available (backward compatible).

• fnox sync --local-file output target (#317) -- @florian-lackner365
  fnox sync now accepts a --local-file flag that writes sync overrides to the local override file (fnox.local.toml or .fnox.local.toml) next to your config file, instead of modifying the main config. This keeps encrypted sync caches out of version control. The flag requires the config filename to be fnox.toml or .fnox.toml (other filenames are rejected) and conflicts with --global.

  fnox sync -p age --local-file
  # writes to fnox.local.toml (add to .gitignore)
  

Fixed

• Auth prompts now work in batch providers (#349) -- @johnpyp
  When a batch provider (e.g. AWS KMS resolving multiple secrets at once) returned an auth error, the auth_command fallback was not triggered -- the secrets were silently skipped. Batch resolution now detects auth errors in the results, runs the configured auth command (e.g. aws sso login), and retries the batch.

Changed

• YubiKey provider loads libusb dynamically (#348) -- @jdx
  The yubico_manager crate has been replaced with a minimal reimplementation that loads libusb at runtime via libloading. Previously, libusb was linked at build time, which caused the binary to crash on startup (dyld errors on macOS) for users who did not have Homebrew libusb installed -- even if they never used the YubiKey provider. Now the binary starts normally on all systems, and users who try to use the YubiKey provider without libusb get a clear error with platform-specific install instructions.

New Contributors

• @florian-lackner365 made their first contribution in #317
• @johnpyp made their first contribution in #349

Full Changelog: v1.17.0...v1.18.0

Highlights

MCP server for AI agents -- fnox mcp starts a session-scoped secret broker over stdio, letting AI agents like Claude Code access secrets without having them directly in the environment.

Cloudflare and GitHub App lease backends -- Create short-lived, scoped Cloudflare API tokens and GitHub App installation tokens with automatic expiry and revocation support.

fnox get resolves leases -- Requesting a key that a lease backend produces (e.g. fnox get AWS_ACCESS_KEY_ID) now resolves the lease automatically, with caching.

XDG-compliant directories -- Lease ledger storage now follows the XDG spec, moving from ~/.config/fnox/leases/ to ~/.local/state/fnox/leases/ with automatic migration.

Added

• MCP server for secret-gated AI agent access (#343) -- @jdx
  The new fnox mcp command starts a Model Context Protocol server over stdio with two tools: get_secret (retrieve a secret by name) and exec (run a command with secrets injected as env vars). Secrets are batch-resolved on first access and cached in memory for the session. Tools can be selectively enabled via config:
  [mcp]
  tools = ["get_secret", "exec"] # default: both enabled
  Configure in .claude/settings.json:
  {
  "mcpServers": {
  "fnox": {
  "command": "fnox",
  "args": ["mcp"]
  }
  }
  }

• Cloudflare API token lease backend (#335) -- @jdx
  A new cloudflare lease backend creates short-lived, scoped Cloudflare API tokens. A parent token with API Tokens: Edit permission creates child tokens that automatically expire. Supports user-owned and account-owned tokens, explicit policies or parent-inherited policies, and configurable duration up to 24 hours.
  [leases.cf]
  type = "cloudflare"
  account_id = "abc123def456"
  duration = "1h"
  [[leases.cf.policies]]
  effect = "allow"
  resources = { "com.cloudflare.api.account.{account_id}" = "*" }
  [[leases.cf.policies.permission_groups]]
  id = "c8fed203ed3043cba015a93ad1616f1f"
  name = "Zone Read"

• GitHub App installation token lease backend (#342) -- @jdx
  A new github-app lease backend creates short-lived GitHub installation access tokens (1 hour max, GitHub's hard limit). Supports scoping to specific permissions and repositories, GitHub Enterprise via api_base, and token revocation via the GitHub API.
  [leases.github]
  type = "github-app"
  app_id = "12345"
  installation_id = "67890"
  private_key_file = "~/.config/fnox/github-app.pem"
  [leases.github.permissions]
  contents = "read"
  pull_requests = "write"

• fnox get resolves leased credentials (#338) -- @jdx
  fnox get now checks if the requested key is produced by a configured lease backend before falling back to provider secret resolution. For example, fnox get AWS_ACCESS_KEY_ID will resolve through the AWS STS lease backend (with caching) if one is configured.

• fnox lease defaults to creating all leases (#337) -- @jdx
  fnox lease create no longer requires a backend name -- omitting it (or passing --all) creates leases for all configured backends sequentially. Secrets are resolved once upfront and shared across backends. fnox lease with no subcommand also defaults to lease create --all.

• FIDO2 PIN masking (#334) -- @jdx
  FIDO2 PIN prompts now mask input with asterisks during typing, preventing shoulder-surfing.

• fnox init -f (#329) -- @jdx
  Added -f as a short alias for --force on the init command, consistent with import and sync.

Fixed

• XDG-compliant directory locations (#336) -- @jdx
  Lease ledger files are now stored under ~/.local/state/fnox/leases/ (or $XDG_STATE_HOME/fnox/leases/), following the XDG Base Directory spec. Config resolution now honors $XDG_CONFIG_HOME. Existing ledger files are automatically migrated on first access. A new FNOX_STATE_DIR env var overrides the state directory.

• fnox exec signal handling and silent exit (#339) -- @jdx
  fnox exec now forwards SIGINT and SIGTERM to the child process so Ctrl-C and kill reach it properly. On subprocess failure, fnox exits silently with the child's exit code (128+signal for signal deaths) instead of printing a noisy error message. Temp files from as_file secrets are now properly cleaned up via Rust destructors.

• fnox set writes to the correct config file (#331) -- @jdx
  fnox set now writes to the lowest-priority existing config file in the current directory instead of always targeting fnox.toml. If only fnox.local.toml exists, secrets are written there. If a non-default profile is active and a profile-specific file exists (e.g. fnox.staging.toml), secrets are written there.

• TUI skips interactive-auth providers (#333) -- @jdx
  fnox tui now skips FIDO2 and YubiKey providers that require physical interaction, preventing display corruption from provider stderr output and input prompts. An error message directs users to fnox exec instead.

• Removed duplicate FIDO2 touch prompt (#332) -- @jdx
  Removed the redundant "Touch your FIDO2 key..." message -- the underlying library already prints its own touch prompt.

Breaking Changes

• Lease ledger location moved -- Lease ledger files have moved from ~/.config/fnox/leases/ to ~/.local/state/fnox/leases/. Existing files are migrated automatically, but if you have scripts that reference the old path directly, update them to use ~/.local/state/fnox/leases/ or the FNOX_STATE_DIR env var.

• fnox exec exit behavior changed -- fnox exec no longer prints an error message or returns a CommandExitFailed error when the subprocess fails. It exits silently with the child's exit code. If you were parsing fnox's error output to detect subprocess failures, check the exit code instead.

• fnox lease create backend name is now optional -- Running fnox lease create without arguments now creates all configured leases instead of printing a usage error. Scripts that relied on the missing-argument error should be updated.

Full Changelog: v1.16.1...v1.17.0

Fixed

• fnox set now fails on encryption errors (#324) -- @jdx

• Previously, fnox set caught encryption errors from any provider (age, AWS KMS, Azure KMS, GCP KMS, FIDO2, YubiKey) and silently fell back to storing the secret as plaintext. This meant a misconfigured or unreachable encryption provider would result in unencrypted secrets in your config file with only a warning in the logs.

• Encryption failures are now hard errors -- fnox set will exit with a non-zero status and an error message instead of quietly storing plaintext.

• Fixed Linux cross-compilation (#326) -- @jdx

Cross-compiled Linux builds (x86_64-unknown-linux-gnu and aarch64-unknown-linux-gnu) were failing due to a missing libudev-dev system dependency required by the hidapi crate. A Cross.toml configuration now ensures the dependency is installed in the cross-compilation Docker containers.

Added

• Custom endpoint for AWS providers (#324) -- @jdx

  The AWS KMS (aws-kms), Secrets Manager (aws-sm), and Parameter Store (aws-ps) providers now accept an optional endpoint field. This lets you point them at LocalStack, MinIO, or any other AWS-compatible API endpoint. Add it to your provider config like so:

  [providers.kms]
  type = "aws-kms"
  key_id = "alias/my-key"
  region = "us-east-1"
  endpoint = "<your-custom-endpoint-url>"
  

Breaking Changes

• If you previously relied on fnox set silently falling back to plaintext when encryption failed, this behavior is removed. Encryption errors now cause the command to fail. Review any scripts or CI pipelines that call fnox set with encryption providers to ensure the provider is correctly configured and reachable.

Full Changelog: v1.16.0...v1.16.1

Fixed

This patch release fixes a bug in fnox sync where re-running sync would read from the cached sync value instead of re-fetching from the original source provider. It also delivers a significant performance improvement for all CLI-based providers by switching to async process execution.

fnox sync preserves original provider reference (#309) -- @jdx

Previously, fnox sync overwrote the secret's provider and value fields with the target provider's encrypted output. This meant re-running sync would try to decrypt the already-synced value instead of fetching fresh data from the original source.

Sync now stores encrypted output in a separate sync field, keeping the original provider reference intact:

Before sync

DATABASE_URL = { provider = "1password", value = "op://vault/db/url" }

After sync -- original provider is preserved

DATABASE_URL = { provider = "1password", value = "op://vault/db/url", sync = { provider = "age", value = "AGE-ENCRYPTED..." } }

When resolving secrets, fnox checks the sync cache first and falls back to the main provider if no cache exists. Re-running fnox sync clears the cache and re-fetches from the original source.

Changed

Async process execution for CLI-based providers (#308) -- @jdx

All seven CLI-based providers (1Password, Bitwarden, Bitwarden Secrets Manager, HashiCorp Vault, password-store, Proton Pass, and Infisical) now use tokio::process::Command instead of blocking std::process::Command. This allows fnox to run multiple CLI calls concurrently when fetching secrets in batch, rather than blocking the async runtime on each call.

For workloads with many secrets from CLI-based providers, this can reduce total fetch time from N * latency to roughly latency (with up to 10 concurrent processes).

Full Changelog: v1.15.0...v1.15.1

Highlights

This release introduces the fnox sync command for re-encrypting remote secrets with a local provider, adds Nushell as a supported shell, and lets you override the authentication command on a per-provider basis. It also includes several provider fixes and fills gaps in provider add coverage.

• fnox sync command: Fetch secrets from remote providers and re-encrypt them locally (e.g., with age or AWS KMS) for CI/CD pipelines or offline environments.
• Nushell integration: Full shell integration support for Nushell, including automatic secret loading on directory change.
• Per-provider auth_command: Override or disable the default auth prompt command for any provider instance in your config.
• Vault address fallback: The HashiCorp Vault provider no longer requires address in config -- it falls back to VAULT_ADDR automatically.

Added

• fnox sync command (#298) -- @jdx

  • Syncs secrets from remote providers to a local encryption provider. This is useful for CI/CD environments or offline setups where you want secrets encrypted locally (e.g., with age) rather than fetched from a remote provider at runtime.

  • # Sync all remote secrets to your age provider
    fnox sync -p age
    

  • # Preview what would be synced
    fnox sync -p age --dry-run
    

  • # Sync only secrets from a specific source provider
    fnox sync -p age --source aws
    

  • # Sync specific keys or filter by regex
    fnox sync -p age MY_SECRET ANOTHER_SECRET
    

  • fnox sync -p age --filter "^DB_"
    

  • Supports --force to skip confirmation, --global to write to the global config, and --source/--filter/positional key arguments for filtering.

• Nushell integration (#304) -- Thanks @tiptenbrink!

  • fnox now supports Nushell (0.96+) as a shell integration target. Since Nushell doesn't support eval, the integration uses a JSON-based protocol where hook-env and deactivate output structured JSON that a Nushell wrapper function interprets.

  • # Add to your Nushell config (find it via $nu.config-path):
    mkdir ($nu.data-dir | path join "vendor/autoload")
    fnox activate nu | save -f ($nu.data-dir | path join "vendor/autoload/fnox.nu")
    

• Per-provider auth_command override (#305) -- @jdx

  • You can now override the authentication command for any provider instance. This is particularly useful for alternative CLI backends like rbw for Bitwarden:

  • [providers]
    # Use rbw instead of the default bw CLI
    rbw = { type = "bitwarden", backend = "rbw", auth_command = "rbw unlock" }
    
    # Custom AWS SSO login
    aws = { type = "aws-sm", region = "us-east-1", auth_command = "aws sso login --profile myprofile" }
    
    # Disable auth prompting entirely for this provider
    vault = { type = "vault", auth_command = "" }
    

  • The instance-level auth_command takes priority over the built-in default for each provider type. Setting it to an empty string disables the auth prompt.

• HashiCorp Vault address is now optional (#301) -- Thanks @chermed!

  • The Vault provider's address field is no longer required in config. If omitted, fnox falls back to the FNOX_VAULT_ADDR or VAULT_ADDR environment variable, which is convenient in environments where Vault connectivity is already configured via environment variables.

  • [providers]
    # address will be read from VAULT_ADDR
    vault = { type = "vault", path = "secret/myapp" }
    

• fnox provider add now covers all provider types (#302) -- Thanks @TyceHerrman!

  • The provider add command was missing several provider types that were already supported. It now accepts: bitwarden, bitwarden-sm, keepass, keychain, password-store, plain, and proton-pass. A --vault flag was also added for specifying the default Proton Pass vault:

  • fnox provider add mypass proton-pass --vault "Personal"
    

Fixed

• Auth prompt no longer fires for non-auth errors (#297) -- Thanks @TyceHerrman!
  • Previously, any provider error (including "secret not found" or "field does not exist") would trigger the interactive authentication prompt. Now the prompt only appears for actual authentication failures (ProviderAuthFailed). This also improves the Infisical provider's error classification -- CLI stderr is now parsed into proper error variants (auth failures, secret-not-found, API errors) instead of being lumped into a generic CLI error, and batch mode preserves these structured errors instead of double-wrapping them.

New Contributors

• @chermed made their first contribution in #301
• @tiptenbrink made their first contribution in #304

Full Changelog: v1.14.0...v1.15.0

Highlights

• Proton Pass provider: Retrieve secrets from Proton Pass vaults using the pass-cli CLI, with flexible reference formats and non-interactive auth support.
• AWS Profile support: Pin AWS Parameter Store and Secrets Manager providers to a specific AWS CLI profile, eliminating reliance on the AWS_PROFILE environment variable.
• Base64 encode/decode: Encode secrets on write and decode them on read with new CLI flags, useful for binary or multi-line secrets stored in base64.

Added

• Proton Pass provider (#292) -- Thanks @TyceHerrman!
  A new read-only provider for Proton Pass, using the Proton Pass CLI (pass-cli). Supports multiple reference formats including item, item/field, vault/item/field, full pass:// URIs, and id:ITEM_ID for disambiguating duplicate item names. Authentication environment variables (PROTON_PASS_PASSWORD, PROTON_PASS_TOTP, etc.) are passed through for non-interactive use.

  [providers]
  protonpass = { type = "proton-pass", vault = "Personal" }
  
  [secrets]
  MY_SECRET = { provider = "protonpass", value = "item-name" }
  MY_USER = { provider = "protonpass", value = "item-name/username" }
  MY_FULL = { provider = "protonpass", value = "pass://Personal/item-name/password" }
  # Use id: prefix for items with duplicate names
  MY_DUP = { provider = "protonpass", value = "id:ITEM_ID/password" }
  

• AWS Profile support for AWS PS and Secrets Manager (#290) -- Thanks @micahvdk!
  Both the AWS Parameter Store (aws-ps) and AWS Secrets Manager (aws-sm) providers now accept an optional profile field. This lets you pin a provider to a specific AWS CLI profile from ~/.aws/config, which is useful when managing secrets across multiple AWS accounts without depending on the AWS_PROFILE environment variable.

  [providers]
  ps = { type = "aws-ps", region = "us-east-1", profile = "prod-account", prefix = "/myapp/prod/" }
  aws = { type = "aws-sm", region = "us-west-2", profile = "prod-account", prefix = "myapp/" }
  

• Base64 encode/decode for secrets (#273) -- Thanks @pitoniak32!
  New CLI flags for base64 encoding and decoding secrets:

  fnox set --base64-encode KEY VALUE -- base64-encodes the value before storing it
  fnox get --base64-decode KEY -- base64-decodes the stored value before outputting it
  

  This is useful for secrets that contain binary data or multi-line content that needs to be stored in a base64-safe format.

Fixed

• AWS Secrets Manager batch request deduplication (#296)
  When multiple config keys referenced the same underlying AWS Secrets Manager secret (e.g., using json_path to extract different fields from one JSON secret), the BatchGetSecretValue API call would fail due to duplicate secret IDs. Secret IDs are now deduplicated before the batch request, and results are fanned out to all keys that reference the same secret.

New Contributors

• @pitoniak32 made their first contribution in #273
• @TyceHerrman made their first contribution in #292
• @micahvdk made their first contribution in #290

Full Changelog: v1.13.0...v1.14.0