Skip to content

The issue of ocx doctor displaying different results for HTTP_PROXY #59

Closed

Description

@guigeng

Currently, the proxy server configuration is automatically extracted from environment variables. At startup, the following environment variables must be present for the proxy server to take effect: HTTP_PROXY, HTTPS_PROXY, ALL_PROXY, and NO_PROXY.

However, I encountered a problem: during startup, if I execute ocx doctor in the terminal that started ocx start or ocx service start, these variables correctly show as set. But if I create a new terminal and execute ocx doctor, it shows as unset.

Activity

  1. Ingwannu commented on Jul 3, 2026

    @Ingwannu
    Owner

    Thanks for the report. This is expected shell/process behavior, but the current ocx doctor output is misleading.

    ocx doctor currently reports the proxy variables visible to the ocx doctor process itself. Environment variables are inherited by child processes, not shared globally between existing terminals, so a new terminal will not automatically see variables that were exported only in the terminal that launched ocx start / ocx service start.

    I opened #60 to make this clearer. The PR splits the doctor output into:

    • current doctor process proxy env
    • configured config.proxy state, with values hidden
    • running opencodex proxy process proxy env on Linux/WSL when the recorded PID can be inspected

    This should let users distinguish “this terminal has no proxy env” from “the running proxy process has no proxy env” without printing proxy URLs or credentials.

  2. Ingwannu commented on Jul 3, 2026

    @Ingwannu
    Owner

    Merged the doctor proxy-env diagnostics fix into dev via #60. Closing this for now; please reopen or comment if the new doctor output still looks misleading.

  3. guigeng commented on Jul 3, 2026

    @guigeng
    Author

    There's a setting 'proxy' in config.json that wasn't mentioned in the documentation (https://lidge-jun.github.io/opencodex/reference/configuration/).
    I added "proxy": "http://127.0.0.1:7890" to the top-level field of ~/.opencodex/config.json and then restarted the service. This seems to work a bit better.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions