docs: update sbx secret scope syntax

content/manuals/ai/sandboxes/agents/claude-code.md

@@ -35,7 +35,7 @@ Claude Code requires either an Anthropic API key or a Claude subscription.
 [stored secrets](../security/credentials.md#stored-secrets):
 
 ```console
-$ sbx secret set -g anthropic
+$ sbx secret set anthropic
 ```
 
 **Claude subscription**: If no API key is set, use the `/login` command inside

content/manuals/ai/sandboxes/agents/codex.md

@@ -38,7 +38,7 @@ To set up authentication ahead of time, choose one of the following methods.
 **OAuth**: Start the OAuth flow on your host with:
 
 ```console
-$ sbx secret set -g openai --oauth
+$ sbx secret set openai --oauth
 ```
 
 This opens a browser window for authentication and stores the resulting tokens
@@ -49,7 +49,7 @@ so browser-based authentication works without any extra setup.
 [stored secrets](../security/credentials.md#stored-secrets):
 
 ```console
-$ sbx secret set -g openai
+$ sbx secret set openai
 ```
 
 See [Credentials](../security/credentials.md) for more details.

content/manuals/ai/sandboxes/agents/copilot.md

@@ -33,7 +33,7 @@ Copilot requires a GitHub token with Copilot access. Store your token using
 [stored secrets](../security/credentials.md#stored-secrets):
 
 ```console
-$ echo "$(gh auth token)" | sbx secret set -g github
+$ echo "$(gh auth token)" | sbx secret set github
 ```
 
 ## Configuration

content/manuals/ai/sandboxes/agents/cursor.md

@@ -35,7 +35,7 @@ Cursor supports two authentication methods: an API key or OAuth.
 [stored secrets](../security/credentials.md#stored-secrets):
 
 ```console
-$ sbx secret set -g cursor
+$ sbx secret set cursor
 ```
 
 **OAuth**: If no API key is set, Cursor prompts you to sign in interactively

content/manuals/ai/sandboxes/agents/docker-agent.md

@@ -26,13 +26,13 @@ Docker Agent supports multiple providers. Store keys for the providers you want
 to use with [stored secrets](../security/credentials.md#stored-secrets):
 
 ```console
-$ sbx secret set -g openai
-$ sbx secret set -g anthropic
-$ sbx secret set -g google
-$ sbx secret set -g xai
-$ sbx secret set -g nebius
-$ sbx secret set -g mistral
-$ sbx secret set -g openrouter
+$ sbx secret set openai
+$ sbx secret set anthropic
+$ sbx secret set google
+$ sbx secret set xai
+$ sbx secret set nebius
+$ sbx secret set mistral
+$ sbx secret set openrouter
 ```
 
 You only need to configure the providers you want to use. Docker Agent detects

content/manuals/ai/sandboxes/agents/droid.md

@@ -37,7 +37,7 @@ your Factory account.
 [stored secrets](../security/credentials.md#stored-secrets):
 
 ```console
-$ sbx secret set -g droid
+$ sbx secret set droid
 ```
 
 **OAuth**: If no API key is set, Droid prompts you to authenticate

content/manuals/ai/sandboxes/agents/gemini.md

@@ -35,7 +35,7 @@ Gemini requires either a Google API key or a Google account with Gemini access.
 [stored secrets](../security/credentials.md#stored-secrets):
 
 ```console
-$ sbx secret set -g google
+$ sbx secret set google
 ```
 
 **Google account**: If no API key is set, Gemini prompts you to sign in

content/manuals/ai/sandboxes/agents/opencode.md

@@ -36,13 +36,13 @@ OpenCode supports multiple providers. Store keys for the providers you want to
 use with [stored secrets](../security/credentials.md#stored-secrets):
 
 ```console
-$ sbx secret set -g openai
-$ sbx secret set -g anthropic
-$ sbx secret set -g google
-$ sbx secret set -g xai
-$ sbx secret set -g groq
-$ sbx secret set -g aws
-$ sbx secret set -g openrouter
+$ sbx secret set openai
+$ sbx secret set anthropic
+$ sbx secret set google
+$ sbx secret set xai
+$ sbx secret set groq
+$ sbx secret set aws
+$ sbx secret set openrouter
 ```
 
 You only need to configure the providers you want to use. OpenCode detects
@@ -57,7 +57,7 @@ OpenCode Zen API keys aren't part of the built-in OpenCode credentials that
 Set the `OPENCODE_API_KEY` environment variable on the host, then store it:
 
 ```console
-$ sbx secret set-custom -g \
+$ sbx secret set-custom \
     --host opencode.ai \
     --env OPENCODE_API_KEY \
     --value "$OPENCODE_API_KEY"
@@ -73,8 +73,8 @@ OpenCode Zen also requires network access to `opencode.ai`:
 $ sbx policy allow network opencode.ai:443
 ```
 
-If you add the custom secret globally with `-g`, recreate existing OpenCode
-sandboxes so the new environment variable is available inside the sandbox.
+If you add a global custom secret, recreate existing OpenCode sandboxes so the
+new environment variable is available inside the sandbox.
 
 ## Configuration
 

content/manuals/ai/sandboxes/agents/shell.md

@@ -38,8 +38,8 @@ before running the sandbox. The proxy injects them into outbound API requests;
 credentials are never stored inside the VM:
 
 ```console
-$ sbx secret set -g anthropic
-$ sbx secret set -g openai
+$ sbx secret set anthropic
+$ sbx secret set openai
 ```
 
 Once inside the shell, you can install agents using their standard methods,

content/manuals/ai/sandboxes/customize/build-an-agent.md

@@ -223,7 +223,7 @@ to look like a real Amp key. Pick a placeholder shape that matches Amp's
 expected format:
 
 ```console
-$ sbx secret set-custom -g \
+$ sbx secret set-custom \
     --host ampcode.com \
     --env AMP_API_KEY \
     --placeholder "sgamp-{rand}" \
@@ -320,7 +320,7 @@ To remove the entry created earlier with `sbx secret set-custom`, pass
 the host to `sbx secret rm`:
 
 ```console
-$ sbx secret rm -g --host ampcode.com
+$ sbx secret rm --host ampcode.com
 ```
 
 The `--host` flag is part of the experimental `set-custom` surface and doesn't appear in `sbx secret rm --help`.

content/manuals/ai/sandboxes/get-started.md

@@ -142,7 +142,7 @@ To give the agent access to GitHub for creating pull requests or interacting
 with repositories:
 
 ```console
-$ sbx secret set -g github -t "$(gh auth token)"
+$ sbx secret set github -t "$(gh auth token)"
 ```
 
 ## Run your first sandbox

content/manuals/ai/sandboxes/security/credentials.md

@@ -74,20 +74,20 @@ more on running sandboxes without a desktop keyring, see
 ### Store a secret
 
 ```console
-$ sbx secret set -g anthropic
+$ sbx secret set anthropic
 ```
 
-This prompts you for the secret value interactively. The `-g` flag stores the
-secret globally so it's available to all sandboxes. To scope a secret to a
-specific sandbox instead:
+This prompts you for the secret value interactively. Service secrets are
+global by default, so the secret is available to all sandboxes. To scope a
+secret to a specific sandbox instead:
 
 ```console
-$ sbx secret set my-sandbox openai
+$ sbx secret set openai --sandbox my-sandbox
 ```
 
 > [!NOTE]
 > A sandbox-scoped secret takes effect immediately, even if the sandbox is
-> running. A global secret (`-g`) only applies when a sandbox is created. If
+> running. A global secret only applies when a sandbox is created. If
 > you set or change a global secret while a sandbox is running, recreate the
 > sandbox for the new value to take effect.
 
@@ -139,7 +139,7 @@ reads and the API domains the proxy injects credentials into:
 | `openrouter` | `OPENROUTER_API_KEY`               | `openrouter.ai`                                                                                                               |
 | `xai`        | `XAI_API_KEY`                      | `api.x.ai`                                                                                                                    |
 
-When you store a secret with `sbx secret set -g <service>`, the proxy injects
+When you store a secret with `sbx secret set <service>`, the proxy injects
 it into requests to the listed API domains.
 
 ### Services declared by kits
@@ -150,7 +150,7 @@ kit-declared service, run `sbx secret set` with the same identifier the kit
 declares under `credentials.sources`:
 
 ```console
-$ sbx secret set -g my-service
+$ sbx secret set my-service
 ```
 
 There's no separate registration step; the keychain entry is keyed on the
@@ -171,7 +171,7 @@ SCOPE      TYPE      NAME      SECRET
 Remove a secret:
 
 ```console
-$ sbx secret rm -g github
+$ sbx secret rm github
 ```
 
 > [!NOTE]
@@ -184,7 +184,7 @@ The `github` service gives the agent access to the `gh` CLI inside the
 sandbox. Pass your existing GitHub CLI token:
 
 ```console
-$ echo "$(gh auth token)" | sbx secret set -g github
+$ echo "$(gh auth token)" | sbx secret set github
 ```
 
 This is useful for agents that create pull requests, open issues, or interact
@@ -215,10 +215,11 @@ when an agent validates the environment variable format at boot, or when the
 credential lands in a request body rather than a header — use
 `sbx secret set-custom`. The secret is keyed on one or more target domains, an
 environment variable name, and an optional placeholder string, instead of a
-service identifier.
+service identifier. Custom secrets are global by default. Pass `--sandbox` to
+scope one to a specific sandbox.
 
 ```console
-$ sbx secret set-custom -g \
+$ sbx secret set-custom \
     --host api.example.com \
     --env API_KEY \
     --value <secret>
@@ -229,7 +230,7 @@ an API is split across related hostnames or when two unrelated endpoints share
 a credential:
 
 ```console
-$ sbx secret set-custom -g \
+$ sbx secret set-custom \
     --host api.example.com \
     --host uploads.example.com \
     --env API_KEY \
@@ -266,21 +267,23 @@ Docker Hub, `sbx` reuses your `sbx login` session — no registry secret needed.
 For other registries (GitHub Container Registry, ECR, ACR, self-hosted Nexus,
 and so on), store credentials with `sbx secret set --registry`.
 
-Choose the scope by adding `-g`, adding a sandbox name, or passing neither:
+Choose the scope by adding `--all-sandboxes`, adding `--sandbox SANDBOX`, or
+passing neither:
 
 ```text
-sbx secret set [-g | SANDBOX] --registry HOST
+sbx secret set [--all-sandboxes | --sandbox SANDBOX] --registry HOST
 ```
 
-- **Host-only** (no `-g`, no `SANDBOX`): the `sbx` CLI uses it to pull templates
+- **Host-only** (no scope flag): the `sbx` CLI uses it to pull templates
   and kits when creating a sandbox. The credential stays on the host and is
   never available inside the sandbox.
-- **Global** (`-g`): same as host-only, plus the host-side proxy authenticates
-  registry login requests from sandboxes. The credential stays on the host and
-  is never written to the sandbox filesystem. Use it when agents build and
-  publish container images.
-- **Sandbox-scoped** (`SANDBOX`): same proxy behavior as global, but only for the
-  named sandbox. Use it when only one sandbox needs registry access.
+- **All sandboxes** (`--all-sandboxes`): same as host-only, plus the proxy
+  authenticates registry login requests from sandboxes. The credential stays
+  on the host and is never written to the sandbox filesystem. Use it when
+  agents build and publish container images.
+- **Sandbox-scoped** (`--sandbox SANDBOX`): same proxy behavior as
+  `--all-sandboxes`, but only for the named sandbox. Use it when only one
+  sandbox needs registry access.
 
 ### Store registry credentials
 
@@ -300,21 +303,21 @@ $ echo "$ACR_PASSWORD" | sbx secret set \
     --password-stdin
 ```
 
-Add `-g` to store the credential globally for sandbox registry operations:
+Add `--all-sandboxes` to make the credential available to every new sandbox:
 
 ```console
-$ gh auth token | sbx secret set -g --registry ghcr.io --password-stdin
+$ gh auth token | sbx secret set --all-sandboxes --registry ghcr.io --password-stdin
 $ sbx run claude
 ```
 
-Store global registry credentials before creating a sandbox. Existing sandboxes
-don't pick up global registry credentials added later. To add registry access to
-an existing sandbox, use a sandbox-scoped credential instead.
+Store all-sandboxes registry credentials before creating a sandbox. Existing
+sandboxes don't pick up all-sandboxes registry credentials added later. To add
+registry access to an existing sandbox, use a sandbox-scoped credential instead.
 
 To scope the credential to a single sandbox, store it under that sandbox's name:
 
 ```console
-$ gh auth token | sbx secret set my-app --registry ghcr.io --password-stdin
+$ gh auth token | sbx secret set --sandbox my-app --registry ghcr.io --password-stdin
 ```
 
 `sbx kit pull` also uses these credentials, with the Docker credential
@@ -323,23 +326,23 @@ push targets still require a prior `docker login`.
 
 ### Remove registry credentials
 
-Remove both the host-only and global entries for a registry:
+Remove both the host-only and all-sandboxes entries for a registry:
 
 ```console
 $ sbx secret rm --registry ghcr.io -f
 ```
 
-To remove only the global (in-sandbox) entry and leave the
-host-only credential in place, pass `-g`:
+To remove only the all-sandboxes entry and leave the host-only credential in
+place, pass `--all-sandboxes`:
 
 ```console
-$ sbx secret rm -g --registry ghcr.io -f
+$ sbx secret rm --all-sandboxes --registry ghcr.io -f
 ```
 
 To remove a sandbox-scoped credential, pass the sandbox name:
 
 ```console
-$ sbx secret rm my-sandbox --registry ghcr.io -f
+$ sbx secret rm --sandbox my-sandbox --registry ghcr.io -f
 ```
 
 ## Best practices
@@ -351,14 +354,14 @@ $ sbx secret rm my-sandbox --registry ghcr.io -f
   pre-configured to use proxy-managed credentials.
 - Registry credentials stay on the host and are injected by the proxy when a
   sandbox authenticates to the registry. Reserve them for sandboxes that need
-  registry access, and prefer sandbox scope over global (`-g`) to limit
+  registry access, and prefer sandbox scope over `--all-sandboxes` to limit
   exposure.
 - Several agents support OAuth as another secure option: the flow runs on the
   host, so the token is never exposed inside the sandbox. If you haven't stored
   a credential, the agent prompts you to authenticate — Codex prompts on the
   host from `sbx run codex`, while Claude Code, Cursor, and Droid prompt
   interactively inside the sandbox. To authenticate ahead of time, run
-  `sbx secret set -g openai --oauth` for Codex or use `/login` inside Claude
+  `sbx secret set openai --oauth` for Codex or use `/login` inside Claude
   Code; Cursor and Droid have no ahead-of-time option, so their sign-in prompt
   appears when the agent starts. See the individual [agent pages](../agents/)
   for each agent's flow.