diff --git a/content/manuals/ai/sandboxes/agents/claude-code.md b/content/manuals/ai/sandboxes/agents/claude-code.md
index daf857d79c5b..8c093a1c98c0 100644
--- a/content/manuals/ai/sandboxes/agents/claude-code.md
+++ b/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
diff --git a/content/manuals/ai/sandboxes/agents/codex.md b/content/manuals/ai/sandboxes/agents/codex.md
index ed7156434d59..de8d90204f6c 100644
--- a/content/manuals/ai/sandboxes/agents/codex.md
+++ b/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.
diff --git a/content/manuals/ai/sandboxes/agents/copilot.md b/content/manuals/ai/sandboxes/agents/copilot.md
index 007a066572a7..29b62f603029 100644
--- a/content/manuals/ai/sandboxes/agents/copilot.md
+++ b/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
diff --git a/content/manuals/ai/sandboxes/agents/cursor.md b/content/manuals/ai/sandboxes/agents/cursor.md
index 15d41517e039..6d02599e6185 100644
--- a/content/manuals/ai/sandboxes/agents/cursor.md
+++ b/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
diff --git a/content/manuals/ai/sandboxes/agents/docker-agent.md b/content/manuals/ai/sandboxes/agents/docker-agent.md
index db8daf227d05..17eda8c947e6 100644
--- a/content/manuals/ai/sandboxes/agents/docker-agent.md
+++ b/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
diff --git a/content/manuals/ai/sandboxes/agents/droid.md b/content/manuals/ai/sandboxes/agents/droid.md
index 18866041b5f7..17fdfd30c3e8 100644
--- a/content/manuals/ai/sandboxes/agents/droid.md
+++ b/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
diff --git a/content/manuals/ai/sandboxes/agents/gemini.md b/content/manuals/ai/sandboxes/agents/gemini.md
index 8dc0e68324bd..98cb1813ce09 100644
--- a/content/manuals/ai/sandboxes/agents/gemini.md
+++ b/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
diff --git a/content/manuals/ai/sandboxes/agents/opencode.md b/content/manuals/ai/sandboxes/agents/opencode.md
index d5bc06679dd5..6d3c0b894e4d 100644
--- a/content/manuals/ai/sandboxes/agents/opencode.md
+++ b/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
 
diff --git a/content/manuals/ai/sandboxes/agents/shell.md b/content/manuals/ai/sandboxes/agents/shell.md
index ec8c8cbda86a..928bfdfa8b57 100644
--- a/content/manuals/ai/sandboxes/agents/shell.md
+++ b/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,
diff --git a/content/manuals/ai/sandboxes/customize/build-an-agent.md b/content/manuals/ai/sandboxes/customize/build-an-agent.md
index 98aec4206f0e..1e920b4c11d8 100644
--- a/content/manuals/ai/sandboxes/customize/build-an-agent.md
+++ b/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`.
diff --git a/content/manuals/ai/sandboxes/get-started.md b/content/manuals/ai/sandboxes/get-started.md
index 651cc51b0092..8cf1b27fb889 100644
--- a/content/manuals/ai/sandboxes/get-started.md
+++ b/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
diff --git a/content/manuals/ai/sandboxes/security/credentials.md b/content/manuals/ai/sandboxes/security/credentials.md
index 241e030b0bc8..f95f5dbe007f 100644
--- a/content/manuals/ai/sandboxes/security/credentials.md
+++ b/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.
diff --git a/content/manuals/ai/sandboxes/workflows.md b/content/manuals/ai/sandboxes/workflows.md
index 1b0e1a27b342..c1d6a1985999 100644
--- a/content/manuals/ai/sandboxes/workflows.md
+++ b/content/manuals/ai/sandboxes/workflows.md
@@ -417,10 +417,10 @@ credential on your host once, and the sandbox either forwards it via the
 proxy or via SSH agent forwarding.
 
 > [!NOTE]
-> The `-g` flag stores a secret globally so all future sandboxes can use it.
-> Sandboxes that already exist when you run `sbx secret set -g` do not
+> Service secrets are global by default, so all future sandboxes can use them.
+> Sandboxes that already exist when you run `sbx secret set` do not
 > receive the updated value. To update a running sandbox, scope the secret to
-> it directly: `sbx secret set <sandbox-name> <service>`.
+> it directly: `sbx secret set <service> --sandbox <sandbox-name>`.
 
 ### GitHub CLI
 
@@ -429,7 +429,7 @@ outbound requests, so `gh` works inside the sandbox without any additional
 configuration:
 
 ```console
-$ echo "$(gh auth token)" | sbx secret set -g github
+$ echo "$(gh auth token)" | sbx secret set github
 ```
 
 The agent can then create pull requests, open issues, comment on PRs, and
@@ -452,9 +452,10 @@ credentials for `sbx` so it can pull private [templates](customize/templates.md)
 and kits when creating a sandbox:
 
 ```console
-$ gh auth token | sbx secret set --registry ghcr.io \
+$ gh auth token | sbx secret set --all-sandboxes --registry ghcr.io \
     --username <github-username> --password-stdin
-$ echo "$ACR_PASSWORD" | sbx secret set --registry myregistry.azurecr.io \
+$ echo "$ACR_PASSWORD" | sbx secret set --all-sandboxes \
+    --registry myregistry.azurecr.io \
     --username myuser --password-stdin
 ```
 
@@ -467,7 +468,7 @@ Images and containers built inside the sandbox run on the sandbox's private
 Docker daemon, not your host's. They're deleted when the sandbox is removed.
 
 For information on how registry credentials differ from other secrets,
-per-registry username requirements, and global versus per-sandbox scoping, see
+per-registry username requirements, and all-sandbox versus per-sandbox scoping, see
 [Registry credentials](security/credentials.md#registry-credentials).
 
 ### Sourcing credentials from 1Password
@@ -478,8 +479,8 @@ Use `op read` to populate stored secrets without pasting values manually. Store
 the value once and it's available to all future sandboxes:
 
 ```console
-$ op read "op://Work/GitHub/token" | sbx secret set -g github
-$ op read "op://Work/Anthropic/credential" | sbx secret set -g anthropic
+$ op read "op://Work/GitHub/token" | sbx secret set github
+$ op read "op://Work/Anthropic/credential" | sbx secret set anthropic
 ```
 
 The real value stays on your host; the sandbox sees the proxy-managed
@@ -554,7 +555,7 @@ To overwrite an existing stored entry, add `--force`. To pass a value from your
 CI provider's secret store, use `-t`. For example, in a GitHub Actions step:
 
 ```yaml
-- run: sbx secret set -g anthropic -t "${{ secrets.ANTHROPIC_API_KEY }}"
+- run: sbx secret set anthropic -t "${{ secrets.ANTHROPIC_API_KEY }}"
 ```
 
 ## Share setup across a team