[docs-scanner] Inconsistent explanation of OAuth limitation for extended agents

Leggi le due spiegazioni in content/manuals/ai/sandboxes/customize/kit-examples.md, nelle sezioni "Customize agent settings" e "Fork an existing agent." Verifica se la limitazione OAuth si applica a tutti gli agenti estesi o solo ai kit di terze parti con schema v2, quindi uniforma la formulazione in modo che l'ambito e il risultato dell'uso di /login siano coerenti in entrambe le sezioni.

Files:

• content/manuals/ai/sandboxes/customize/kit-examples.md
• content/manuals/ai/sandboxes/customize/kit-examples.md (second occurrence)

Issue

The same file gives two different explanations for why OAuth doesn't work with extended agents, and the second explanation contradicts the first.

First occurrence (in "Customize agent settings" section):

Proxy-managed OAuth isn't supported for a third-party kit that extends the built-in claude agent. Store an Anthropic API key on the host before the first launch:

$ sbx secret set anthropic

When you launch the kit for the first time, sbx prompts you to approve its inherited Anthropic credentials. Because this is a third-party schema v2 kit, sbx records your approval as a credential binding. The sandbox receives a sentinel value, and the proxy injects the real API key into requests to the domains declared by the kit.

Warning: The approval prompt also lists OAuth, but OAuth doesn't work for the extended agent. If you use Claude Code's /login command, Claude Code stores the real OAuth tokens inside the sandbox.

Second occurrence (in "Fork an existing agent" section):

The child inherits the built-in image, credentials, network permissions, persistent volumes, settings, MCP integration, and agent instructions. Its sandbox.entrypoint replaces the inherited entrypoint. Proxy-managed OAuth isn't supported for the extended agent, so follow the Anthropic API-key setup before launching it.

The first explanation says OAuth doesn't work and warns that using /login will store real tokens in the sandbox. The second says OAuth isn't supported but doesn't explain what happens if you try to use it. More importantly, the first occurrence says "this is a third-party schema v2 kit" as the reason, but the second occurrence doesn't mention schema version or third-party status at all - it just says extended agents don't support OAuth.

Why this matters

A reader building an extended agent needs to know:

1. Whether OAuth is technically broken or just not recommended
2. What happens if they try to use OAuth anyway
3. Whether this limitation applies to all extended agents or only third-party ones

The current text leaves all three questions partially answered. The first occurrence suggests it's a third-party + schema v2 issue. The second suggests it's any extended agent. A reader can't tell if they're hitting the same limitation twice or two different limitations.

Suggested fix

Consolidate the explanation and state the scope clearly. If the limitation applies to all extended agents (not just third-party ones), say so once and link to it:

In the "Customize agent settings" section:

Extended agents don't support proxy-managed OAuth. Store an Anthropic API key on the host before the first launch:

$ sbx secret set anthropic

When you launch the kit for the first time, sbx prompts you to approve its inherited Anthropic credentials. Because this is a third-party schema v2 kit, sbx records your approval as a credential binding. The sandbox receives a sentinel value, and the proxy injects the real API key into requests to the domains declared by the kit.

Warning: The approval prompt also lists OAuth, but OAuth doesn't work for extended agents. If you use Claude Code's /login command, Claude Code stores the real OAuth tokens inside the sandbox.

In the "Fork an existing agent" section:

The child inherits the built-in image, credentials, network permissions, persistent volumes, settings, MCP integration, and agent instructions. Its sandbox.entrypoint replaces the inherited entrypoint. Follow the Anthropic API-key setup before launching it.

If the limitation is actually specific to third-party kits, then the second occurrence needs to clarify that built-in extended agents (if they exist) don't have this problem.

Found by nightly documentation quality scanner