github jdx/fnox v1.45.0
v1.45.0: Agents can ask you to enter a missing secret, and fnox proxy run serves MCP tools with placeholders

3 hours ago

With fnox 1.45.0, an AI agent can ask you for a missing secret through a one-time local page, so the value never goes through the chat. fnox proxy run can now start before every secret is set, and it serves fnox's MCP tools using placeholders instead of real values. fnox env --describe also reports which file defines each key, and symlinked global configs now work with [files].

Added

  • request_secret MCP tool (#1065, #1074, #1075) by @jdx. When an agent needs a credential you haven't stored yet, it can ask fnox for it by name. fnox serves a one-time page on 127.0.0.1 and sends the link to the MCP client through URL-mode elicitation. You type the value on that page and fnox stores it the same way fnox set does. The agent is told only that the secret was stored, and exec injects it from then on. The tool is off by default:
    default_provider = "age"
    
    [mcp]
    tools = ["exec", "request_secret"]
    • If mcp.secrets is set, the agent can only ask for names on that list. The plain provider is refused. If the secret already has a value, fnox doesn't ask for it again unless the agent passes replace: true.
    • The link works once and expires after 10 minutes. The page rejects cross-site form posts. After you save, a reload shows the result for 60 seconds and doesn't store the value a second time.
    • If the client doesn't support URL-mode elicitation, no page opens. Instead, the agent is told to ask you to run fnox set NAME in your own terminal. If the client rejects or cancels the prompt, or the request times out, the agent gets a message that is different from the one sent when you click Decline. That message also tells the agent not to reopen the prompt or ask for the secret in chat.
    • The input is a single line, so multi-line values such as PEM keys still need fnox set --from-file. The page can't prove that you are the one filling it in. Another program running as your user could submit a value.
  • MCP tools under fnox proxy run (#1072) by @jdx. When an agent runs fnox mcp inside fnox proxy run (including --sandbox), the MCP server now relays to the proxy, and you don't need to change the agent's MCP config. get_secret returns the secret's placeholder instead of its real value. request_secret opens its page from the proxy process, outside the sandbox. After you enter the value, the proxy starts injecting it into matching requests. exec isn't offered in this mode. [mcp] tools and secrets still apply. Only secrets that have a proxy rule can be used this way. Once the child starts, fnox proxy run no longer prompts for provider authentication, so authenticate before you start it.
  • Pending proxy secrets (#1071) by @jdx. Before, fnox proxy run exited if any rule's secret had no value. Now, if a secret is declared but not set, fnox prints a warning, starts anyway, and still gives the command a placeholder. Requests that need the secret get a 403 with a "not set yet" message. When you set the secret, for example with fnox set STRIPE_KEY in another terminal, the next matching request picks it up without a restart. The proxy checks for the value at most once every 3 seconds per secret. A rule that names an undeclared secret is still an error.
    [secrets]
    STRIPE_KEY = { description = "Stripe test key" }
    
    [[proxy.rules]]
    secret = "STRIPE_KEY"
    domain = "api.stripe.com"
  • Key source in fnox env --json --describe (#1059) by @jdx. Each key now has a source field with path, the file whose definition wins, and global, which is true for the global config and the files it imports. Tools such as mise can use this to tell a project's own keys from your personal global ones. The field is left out when fnox can't trace a key to a file. The describe schema version is still 1. In fnox-client, KeyInfo gains source and a with_source builder.
    "source": { "path": "/home/me/.config/fnox/config.toml", "global": true }

Fixed

  • Symlinked global config and source files (#1063) by @jdx. fnox 1.44.0 refused [files] when ~/.config/fnox/config.toml was a symlink, as dotfiles managers such as stow create. Because fnox set --file had already stored the entry, every later command failed. fnox also rejected source files linked into ~/.config/fnox/files/. Both now work. fnox set and fnox reencrypt write through a source link instead of replacing it. They report an error, before storing anything, if the link is broken or points to the config file or to another entry's file. One case is now stricter: a project fnox.toml that is a symlink into the config directory can no longer declare [files].

Full Changelog: v1.44.0...v1.45.0

💚 Sponsor fnox

fnox is built and maintained by @jdx, an open source developer at entire.io, the title sponsor of his open source work.

If fnox handles secrets or config for you or your team, please consider becoming an individual or company sponsor. Your support funds ongoing development and helps keep fnox secure, free, and independent.

Don't miss a new fnox release

NewReleases is sending notifications on new releases.