docker / docker/docs

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

Open
#26,006 0 comments 0 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

Dominant language
Markdown
Stars
4.7k
Forks
8.5k
Avg merge
2d 18h
Merged PRs (30d)
108

Description

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

Contributor guide

Open the contributing guide

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

Research direction

Read the two explanations in content/manuals/ai/sandboxes/customize/kit-examples.md, under "Customize agent settings" and "Fork an existing agent." Confirm whether the OAuth limitation applies to all extended agents or only third-party schema v2 kits, then consolidate the wording so the scope and result of using /login are consistent in both sections.

Written by the indexing model from the issue text.

Assessment

Tech stack
docker
Domain
documentation
Issue type
Documentation
Difficulty
2/5
Estimated time
1-3 hours
Activity status
Active
Clarity
Mostly clear
Newbie friendliness
55/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.