Service eligibility and regional restrictions
PuppyIP serves only compliant overseas businesses and their authorized personnel. Proxy services are not available in mainland China. The service may only be used for lawful business activities outside mainland China. Use of this service within mainland China is prohibited.
Hosting a proxy IP or server overseas does not change these restrictions. The service must not be provided to end users in mainland China through relaying, forwarding, sharing or resale. Before use, read the Terms of Service.
Key Takeaways
- The official October 29, 2026 CLI 0.166.0 update lists --network-only. Check the version and help of the installation actually running; having downloaded an update is insufficient.
- The focused report covers effective configuration, the network environment, provider HTTP reachability, and Responses WebSocket. It skips database and MCP scans.
- If configuration loading fails, the command reports a redacted error and stops without probing guessed targets. Successful loading preserves configuration warnings and load timing.
- HTTP and WebSocket have separate checks. Passing every check does not validate an actual task, tool permissions, account limits, or an integration protocol.
Run it where the CLI actually fails
Run codex --version, then use codex doctor --help to confirm that this installation recognizes --network-only. The official changelog includes the feature in CLI 0.166.0, released on October 29, 2026. The implementation merged a day earlier; a merge date alone is not a release announcement.
Next, run codex doctor --network-only in the same terminal, on the same host, and under the same user environment as the failure. If the problem occurs on a remote development machine, check that machine’s actual CLI environment. A working browser on your laptop does not establish that the remote process uses the same configuration or network path.
What the four checks tell you
Effective configuration establishes the runtime settings available to the diagnostic and preserves recoverable configuration warnings and load timing. The network environment, provider HTTP reachability, and Responses WebSocket checks provide separate clues about the connection path. Responses WebSocket is a persistent connection used to communicate with the model service.
--network-only skips checks from the full doctor report that are unrelated to this purpose, including database and MCP scans. A short network report does not establish that the installation, every tool, or an entire project is healthy. It also does not establish that an MCP server started correctly.
Why a configuration error leaves no network probe results
This is an explicit stopping condition. When configuration cannot load, the command returns a redacted configuration failure explaining that effective network configuration is unavailable. It does not continue by probing guessed addresses. Missing later connection results therefore do not mean that every network target was unreachable.
Check the actual file location, line and column, or error type supplied in the failure, then rerun the same command. Avoid deleting configuration or switching providers merely to obtain a green report: that would compare a different environment with the one that originally failed.
What to inspect when HTTP works but WebSocket fails
Read the two results separately. HTTP reachability does not guarantee that a persistent WebSocket connection succeeds. A failed check also does not, by itself, identify a proxy, account, service outage, or exhausted allowance as the cause. Save the check name, time, and error, then compare them with your provider’s requirements and organizational network policy.
For example, suppose the HTTP check passes in one environment but Responses WebSocket fails. Ask the network administrator to inspect that actual transport path, proxy authentication, and organizational policy. This hypothetical example explains an investigation order; it does not establish the cause. Do not disable TLS verification or bypass organizational controls to force a successful connection.
Keep comparable reports for a handoff
For machine-readable output, use codex doctor --network-only --json. The official command reference describes the JSON report as redacted. Still review it for internal paths, domains, or other information unsuitable for disclosure before sending it to a colleague or public issue. Do not attach real tokens, proxy credentials, or complete configuration files.
Record the CLI version, operating system, affected host, check time, and each result. Change one setting relevant to the error at a time, then rerun in the same environment. Keeping the original report alongside the new one makes a change easier to assess than sharing only a screenshot of a passing result.
After the report passes, verify the original task
Retry a permitted, narrowly scoped version of the original task and check its actual completion state. A passing network report does not grant tool permissions, repair MCP or App Server protocols, or validate task output. Allowances, billing, plans, and regional eligibility remain subject to the service’s own rules.
If the task still fails, put its specific error and the network report on the same timeline, then investigate the relevant layer. This article explains scope from official release notes, the command reference, and merged code. We did not run real account requests or establish that the command automatically repairs connections or resets usage.
Sources
Frequently Asked Questions
What if it reports unknown argument --network-only?
Check codex --version and codex doctor --help to confirm whether the installation actually running includes the 0.166.0 feature. A machine can have multiple installations. Verify or update it through your existing installation method; an unrecognized argument is not evidence of a network failure.
Should I use full doctor or --network-only?
Focused mode reduces unrelated checks when the problem concerns configuration and connectivity. For installation, runtime, database, MCP, or other areas, use the full diagnostic as described by the current command help. Anything outside the focused report remains unchecked.
Does sharing a report establish a service-side outage?
No. It supplies diagnostic evidence for a particular version, environment, and moment. Interpret it alongside the original task error and official status information. A failed check or one entirely passing run does not establish service health for all users.