Skip to content

Feat: Resolve runtime secret refs in tools and providers#2212

Closed
EvanNotFound wants to merge 1 commit intoHKUDS:nightlyfrom
EvanNotFound:feat/support-secret-reference
Closed

Feat: Resolve runtime secret refs in tools and providers#2212
EvanNotFound wants to merge 1 commit intoHKUDS:nightlyfrom
EvanNotFound:feat/support-secret-reference

Conversation

@EvanNotFound
Copy link
Copy Markdown

@EvanNotFound EvanNotFound commented Mar 18, 2026

This PR implements #2172

Before this PR, Nanobot uses raw config object to access values. Both load_config and save_config operates on the same raw config object, which means in order to add secret ref functionality, we need a runtime config as the middleman. However, adding a new layer of config object adds a lot of complexity and will require a full architectural change. So what I did here is building on top of the raw config. I added a helper to resolve secret references, and whenever a module needs secrets, it calls the helper to resolve the secrets at runtime.

Code Changes

  • Add support for {file:...} and {exec:...} config values so secrets do not need to be stored directly in config.json.
  • Resolve these values only at runtime, including provider config, channels, MCP, web tools, workspace path, and shell config.
  • Add tests to cover file refs, command refs, inline usage, and saving config without writing resolved secrets back to disk

- add secret_refs helper to load file/exec based secrets at runtime
- resolve MCP, web, shell, channels, and provider configs via secret refs
- ensure CLI gateway/agent use resolved model and proxy values
- keep config files storing literal secret ref expressions
- extend tests for secret refs, MCP, web search, channels, and CLI config
@chengyongru
Copy link
Copy Markdown
Collaborator

Hi @EvanNotFound! Thanks for this contribution.

I took a closer look at your implementation - it's quite comprehensive! However, I think there might be a simpler approach.

Since nanobot already uses environment variables extensively, what if we just use {env:VAR_NAME} syntax directly in config.json, and resolve them in one place (e.g., config loader)?

This would:
Keep changes minimal
Avoid modifying 10+ modules
Align with how most projects handle secrets
What do you think?

see: #2218

@EvanNotFound
Copy link
Copy Markdown
Author

@chengyongru i reviewed the pr in #2218

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants