Repository navigation
[Bug]: Local provider warning requires allowPrivateNetwork but the option is unavailable #175
Description
Activity
Local RCA on
opencodex 2.7.27/25f21128:Confirmed cause
This is a GUI/API integration gap around the SSRF hardening, not an upstream connectivity failure.
-
The backend flag is real and is provider-scoped:
src/config.ts:290-295acceptsproviders.<name>.allowPrivateNetwork.src/lib/destination-policy.ts:113-120bypasses the private/local destination rejection when that exact field istrue.src/server/management-api.ts:506-513even returns the persisted value.
-
The Add Provider GUI cannot send it:
gui/src/provider-payload.ts:1-8has no form field for it.gui/src/provider-payload.ts:27-52has no payload property or builder branch for it.- Therefore a custom localhost provider always reaches
POST /api/providerswithout the required opt-in.
-
The apparent manual fallback in the classic dashboard is nonfunctional:
- The visible JSON editor saves with
PUT /api/configatgui/src/pages/Providers.tsx:310-324. - The server unconditionally returns 405 for that endpoint at
src/server/management-api.ts:225-226. - The UI reduces that response to a generic “save failed”, hiding the actual 405 message.
- The visible JSON editor saves with
-
Existing-provider PATCH cannot set it either:
- The field mask in
src/server/management-api.ts:600-650does not includeallowPrivateNetwork. - A flag-only PATCH reaches
src/server/management-api.ts:652and returns “no recognized fields to update”.
- The field mask in
Live non-mutating probes
POST /api/providers (custom localhost provider, no flag) HTTP 400 {"error":"provider issue-175-local-probe baseUrl points to a localhost destination; set allowPrivateNetwork:true only for intentionally local/self-hosted providers"} PUT /api/config HTTP 405 {"error":"Full config PUT is disabled. Use /api/providers POST for provider changes."} PATCH /api/providers?name=zenmux {"allowPrivateNetwork":true} HTTP 400 {"error":"no recognized fields to update"}The rejected probe did not persist, and the existing provider was unchanged.
Verification
bun test tests/server-auth.test.ts --test-name-pattern 'private-network destinations' 2 pass 54 filtered out 0 failThe passing tests at
tests/server-auth.test.ts:664-721prove the backend rejects the same request without the flag and accepts/persists it when the POST payload includes the flag. That rules out the config schema as the cause.Logging gap
~/.opencodex/service.logcontains none of the validation errors above and was not modified by the probes. These management API 4xx responses are returned directly to the browser, so “check the service log” currently gives no evidence for this failure.Suggested acceptance criteria
- Add an explicit, warned “Allow local/private network” opt-in to the custom provider form.
- Include
allowPrivateNetworkin the POST payload and existing-provider PATCH field mask. - Surface the server response body on JSON-editor save failures, or remove/replace the editor because full config PUT is intentionally disabled.
- Add GUI payload tests covering localhost both without and with explicit opt-in.
-
Additional supported-path check:
ocx provider add issue-175-cli-probe \ --adapter openai-chat \ --base-url http://localhost:1/v1 \ --allow-private-network \ --json Unknown flag(s): --allow-private-network Usage: ocx provider add <name> [--adapter <adapter>] [--base-url <url>] [--api-key <key>] [--default-model <model>] [--set-default] [--force] [--json] [--sync]The rejected CLI probe made no config change. A repository search also finds no user-facing documentation for either
allowPrivateNetworkor an--allow-private-networkflag.So the supported input surfaces are currently closed in all four places:
- Add Provider form omits the field.
- Existing-provider PATCH rejects it as unrecognized.
- Classic JSON editor calls the intentionally disabled full-config PUT.
- CLI has no equivalent flag.
The only current manual workaround is editing the on-disk provider object at
~/.opencodex/config.json -> providers.<name>.allowPrivateNetworkand restarting the proxy, because the running server loads the file at startup and does not watch it for changes.- added a commit that references this issue
on Jul 20, 2026 Fixed on dev (commit f2fa0c2). The
allowPrivateNetworkcheckbox is now exposed in the provider dashboard for built-in presets (not just custom/local providers), with the existing security warning displayed next to the opt-in. Will ship in the next release.- added a commit that references this issue
on Sep 17, 2026
Summary
A provider configured with a localhost
baseUrlcannot be saved or used because OpenCodex reports:The message instructs the user to enable
allowPrivateNetwork: true, but the provider dashboard has no such option. Adding the field manually to the provider configuration also does not make the configuration usable, so the warning currently points to an unavailable escape hatch.Expected behavior:
allowPrivateNetwork: true, with the error message naming the exact config location.Reproduction
9rtr.baseUrlto a redacted local endpoint such ashttp://localhost:<port>/v1.allowPrivateNetwork:trueerror.allowPrivateNetwork: truemanually to the provider config: it is not usable through the current config path.Logs and screenshots
Additional runtime/config-path evidence will be attached after local log inspection.
Area
GUI dashboard
Version
opencodex 2.7.2725f21128ondevOS
macOS 27.0 (26A5378n)
Config shape
{ "provider": "9rtr", "baseUrl": "http://localhost:<port>/v1", "allowPrivateNetwork": true }The endpoint and credentials are redacted.
Checks