feat(cli): support attaching arbitrary OpenShell providers for non-inference credentials

[aslanshi]

Problem Statement

Summary

NemoClaw's onboard wizard only creates OpenShell providers for inference endpoints (nvidia, openai, anthropic types) and messaging bridges (generic type). Users who need to pass additional secrets to the sandbox — such as a Tavily Search API key, or any other third-party service credential — have no NemoClaw-native way to register them as OpenShell providers.

OpenShell itself supports creating and attaching arbitrary providers to sandboxes (openshell provider create --name <name> --type <type> --credential <ENV>), which keeps raw secrets out of the sandbox by injecting them at the L7 proxy layer. NemoClaw abstracts this away during onboard and does not expose it elsewhere.

Current behavior

• The onboard wizard creates providers only for a hardcoded set of inference and messaging credentials (bin/lib/onboard.js:110-175,
  bin/lib/onboard.js:590-630). Prompted secrets are saved to ~/.nemoclaw/credentials.json (mode 600, host-only) and then separately registered as OpenShell providers via
  upsertProvider(), but for other keys not covered, there is no way to add them while running the onboard wizard.
• The current workaround is to pass those secrets as environment variables inside the sandbox but thus become readable by the agent, defeating the credential isolation that OpenShell providers are designed to enforce.
• Currently one could create new provider via OpenShell cli but to attach it to a sandbox one has to recreate a new one and it can't be done with the NemoClaw onboard wizard, so the only choice becomes to build everything from scratch with just OpenShell.

Proposed Design

Expected behavior

Users should be able to register arbitrary secrets as OpenShell providers through NemoClaw so that:

1. The secret flows through OpenShell's L7 proxy credential injection, never exposed as a raw env var inside the sandbox.
2. The network policy preset for the corresponding service (e.g. tavily.yaml) controls which endpoint the credential is injected into.

Suggested scope

1. Upstream (OpenShell): OpenShell should support attaching/detaching providers to an existing sandbox post-creation (e.g. openshell provider attach <provider> <sandbox>). Currently, providers can be created in the gateway but there is no documented CLI path to attach them to a running sandbox after sandbox create.
2. NemoClaw CLI command: Once OpenShell exposes post-creation provider attachment, add nemoclaw <sandbox> provider-add — prompts for provider name, credential env var name, provider type, and optional base URL; calls the upstream attach command under the hood.
3. Onboard extension (optional): Add a "Custom credentials" step after inference/messaging setup that lets users register additional providers during onboard. so that the arguments can be passed to openshell sandbox create under the hood.

Alternatives Considered

No response

Category

enhancement: feature

Checklist

• I searched existing issues and this is not a duplicate
• This is a design proposal, not a "please build this" request

[wscurran]

✨ Thanks for submitting this enhancement proposal, which suggests adding support for attaching arbitrary OpenShell providers for non-inference credentials, making it easier to manage secrets in the sandbox.