Feature Request: Configurable Secret Injection for Custom Services

[hlaebe]

Summary
The current credential proxy only supports a fixed set of predefined services (Anthropic, OpenAI, GitHub, Google, etc.). There is no way to extend this mechanism for custom or self-hosted REST APIs.

Use Case
Many developers use self-hosted services like Redmine, Gitea, Nextcloud, or internal REST APIs that require API key authentication. When running a coding agent inside a Docker Sandbox, there is currently no secure way to provide these credentials — the only options are:

• Storing the API key as an environment variable directly inside the sandbox (where the agent process can read it)
• Placing credentials in a .env file in the workspace (stored in plaintext on disk)

Both approaches undermine the security model that Docker Sandboxes is designed to provide.

Proposed Solution
Allow users to define custom service mappings in a configuration file, for example:

# ~/.sandboxd/custom-services.yaml
services:
  - name: redmine
    env_var: REDMINE_API_KEY
    inject_as: header
    header_name: X-Redmine-API-Key
    domains:
      - redmine.example.com
      - 192.168.1.100:3000

  - name: my-internal-api
    env_var: INTERNAL_API_TOKEN
    inject_as: header
    header_name: Authorization
    header_prefix: "Bearer "
    domains:
      - api.internal.local:8080

Secret Storage — Keeping the Existing Security Model Intact
The YAML configuration would only define metadata (header name, target domains, keychain lookup key). The actual secret value would continue to be stored exclusively in the OS keychain — exactly as it works today for built-in services:

sbx secret set redmine
# → prompts interactively for the key value
# → stores it encrypted in the OS keychain (macOS Keychain / Windows Credential Manager)

At runtime, the proxy would:

1. Read the YAML config → "for Redmine domains, inject X-Redmine-API-Key"
2. Retrieve the actual value from the OS keychain
3. Inject the header into the outgoing request

The raw credential value would never enter the sandbox VM. This is identical to how built-in services work today — the only difference is that the service-to-domain mapping would be user-configurable instead of hardcoded.

Why This Matters
The proxy-based injection is one of the strongest security features of Docker Sandboxes. Limiting it to a hardcoded list of public cloud services means that developers working with self-hosted or enterprise tooling are forced to fall back to less secure methods, which partially defeats the purpose of the sandbox isolation model.

Alternatives Considered

• Running a custom proxy on the host that injects headers before forwarding to the target service — functional but adds operational overhead and complexity
• Mounting credentials via environment variables or .env files — works but exposes secrets to the agent process

Environment

• sbx CLI (Docker Sandboxes)
• Use case: self-hosted Redmine instance on local network