Conversation
…s.md Add a new 'Custom API Endpoints' subsection under 'Engine Environment Variables' documenting that OPENAI_BASE_URL (codex) and ANTHROPIC_BASE_URL (claude) are automatically picked up by the AWF sandbox proxy to route API calls to internal LLM routers, Azure OpenAI, or other custom endpoints. From PR #20631 (merged 2026-03-12T14:02Z, after DDUw's 06:23Z run). Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
There was a problem hiding this comment.
Pull request overview
Adds missing documentation for custom upstream LLM API endpoint routing when OPENAI_BASE_URL / ANTHROPIC_BASE_URL are set in engine.env, aligning docs with behavior introduced in #20631.
Changes:
- Documented
OPENAI_BASE_URLandANTHROPIC_BASE_URLspecial handling inengine.env - Added examples showing how to pair custom endpoints with
network.allowed - Described compile-time flag forwarding to AWF (
--openai-api-target/--anthropic-api-target)
💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.
You can also share your feedback on Copilot code review. Take the survey.
| - anthropic-proxy.internal.example.com | ||
| ``` | ||
|
|
||
| The custom hostname is extracted from the URL and passed to the AWF `--openai-api-target` or `--anthropic-api-target` flag automatically at compile time. No additional configuration is required. |
There was a problem hiding this comment.
This paragraph currently says “The custom hostname is extracted … No additional configuration is required.” Two accuracy issues: (1) the implementation extracts the host (and optional port), and ignores scheme/path; calling it only a “hostname” is slightly misleading, especially for localhost/ports. (2) Workflows typically still need to allow the extracted host in network.allowed (as your example already notes), so “no additional configuration” is easy to misread. Suggest rephrasing to explicitly say it forwards the extracted host[:port] as --openai-api-target/--anthropic-api-target, and that you may need to add the domain to network.allowed for the firewall.
| The custom hostname is extracted from the URL and passed to the AWF `--openai-api-target` or `--anthropic-api-target` flag automatically at compile time. No additional configuration is required. | |
| The custom host (including any port) is extracted from the base URL (scheme and path are ignored) and automatically forwarded at compile time as the AWF `--openai-api-target` or `--anthropic-api-target` flag. You may still need to add the extracted host (and port, if applicable) to `network.allowed` so the firewall permits outbound requests. |
|
|
||
| #### Custom API Endpoints | ||
|
|
||
| Two environment variables receive special treatment when set in `engine.env`: `OPENAI_BASE_URL` (for `codex`) and `ANTHROPIC_BASE_URL` (for `claude`). When either is present, the AWF sandbox proxy automatically routes API calls to the specified host instead of the default `api.openai.com` or `api.anthropic.com`. Credential isolation and firewall enforcement remain active. |
There was a problem hiding this comment.
The term “AWF sandbox proxy” isn’t used elsewhere in the docs and may be confusing/inconsistent with established terminology (“AWF firewall” / “API proxy sidecar”). Consider renaming this to match existing docs terminology, or add a brief link/clarifier to the network/firewall docs (e.g., docs/src/content/docs/reference/network.md:10,180).
| Two environment variables receive special treatment when set in `engine.env`: `OPENAI_BASE_URL` (for `codex`) and `ANTHROPIC_BASE_URL` (for `claude`). When either is present, the AWF sandbox proxy automatically routes API calls to the specified host instead of the default `api.openai.com` or `api.anthropic.com`. Credential isolation and firewall enforcement remain active. | |
| Two environment variables receive special treatment when set in `engine.env`: `OPENAI_BASE_URL` (for `codex`) and `ANTHROPIC_BASE_URL` (for `claude`). When either is present, the AWF API proxy sidecar automatically routes API calls to the specified host instead of the default `api.openai.com` or `api.anthropic.com`, while the [AWF firewall](/gh-aw/reference/network/#firewall) continues to enforce outbound network policy and credential isolation. |
Self-Healing Documentation Fixes
This PR was automatically created by the Daily Documentation Healer workflow.
Gaps Fixed
engines.md. PR feat: support custom OpenAI and Anthropic API targets in AWF sandbox #20631 (merged 2026-03-12T14:02Z) adds support forOPENAI_BASE_URLandANTHROPIC_BASE_URLinengine.env, causing the AWF sandbox proxy to automatically route API calls to a custom host instead of the hardcodedapi.openai.com/api.anthropic.com. This enables internal LLM routers, Azure OpenAI deployments, and other custom endpoints to work with AWF's credential isolation and firewall features. The behavior was not documented anywhere in the reference docs.Root Cause
DDUw ran at ~04:25 UTC on 2026-03-12 and produced PR #20632 (documenting
--skip-secret, Codexweb-searchdefault,draftpolicy, andpush-to-pull-request-branchwarnings). PR #20631 was merged at 14:02 UTC — nearly 10 hours after DDUw completed. This is the same late-UTC-day blind-spot pattern documented in healer runs #20254, #20412, and #20569: features merged in the afternoon UTC window fall entirely outside DDUw's single early-morning scan.DDUw Improvement Suggestions
Analyzed Issues (last 7 days, label: documentation, state: closed)
dependencies:documentation undersells APMnot_planned— CLI binary help text, notdocs/docs/contentThe custom API endpoint gap was discovered by cross-referencing commits merged after DDUw's last run, not from a closed issue.
Files Changed
docs/src/content/docs/reference/engines.md— added "Custom API Endpoints" subsection documentingOPENAI_BASE_URL/ANTHROPIC_BASE_URLspecial handling inengine.envRelated
References: