Skip to content

macOS intermittent UNKNOWN_CERTIFICATE_VERIFICATION_ERROR for OpenAI/Codex endpoint under proxy conditions #21206

New issue
New issue
Closed as not planned
Closed as not planned
macOS intermittent UNKNOWN_CERTIFICATE_VERIFICATION_ERROR for OpenAI/Codex endpoint under proxy conditions#21206
Assignees
iamdavidhill

Description

@atongrun
atongrun
opened on Apr 6, 2026

Description

After updating OpenCode on macOS to 1.3.17, both the desktop app and the CLI started failing with:

unknown certificate verification error

The failing request in the desktop log is specifically:

https://chatgpt.com/backend-api/codex/responses

I was able to reproduce this on macOS with Clash enabled (required for connectivity in my environment). Rolling the CLI back to 1.3.16 on the same machine/network restored normal CLI behavior.

Why this looks like a regression

  • OpenCode 1.3.17 desktop app fails consistently with:
    • UNKNOWN_CERTIFICATE_VERIFICATION_ERROR
  • The desktop log shows:
    • providerID=openai
    • path=https://chatgpt.com/backend-api/codex/responses
  • System TLS to chatgpt.com is fine on the same machine:
    • curl -I https://chatgpt.com succeeds (HTTP 403 from Cloudflare challenge, but TLS is valid)
    • openssl s_client shows a normal chain for chatgpt.com
  • I tested multiple environment configurations on macOS:
    • BUN_OPTIONS=--use-system-ca
    • removing NODE_EXTRA_CA_CERTS / SSL_CERT_FILE
    • explicitly exporting a PEM bundle generated from macOS keychains
  • Even after fixing the shell/launchd environment so the updated OpenCode sidecar inherited the intended values, 1.3.17 app still failed.
  • On the same Mac, I rolled the standalone CLI back from 1.3.17 to 1.3.16, and 1.3.16 CLI works.

This strongly suggests a 1.3.17 regression in the TLS/runtime path used for the OpenAI/Codex request.

OpenCode version

  • Broken: 1.3.17
  • Working after rollback (CLI): 1.3.16

Steps to reproduce

  1. On macOS, install/update OpenCode to 1.3.17
  2. Use OpenAI/Codex from OpenCode in an environment where network access goes through a local proxy/Clash setup
  3. Send a message / trigger a request to the OpenAI provider
  4. Observe:
unknown certificate verification error

Relevant log snippet

From ~/Library/Logs/ai.opencode.desktop/opencode-desktop_2026-04-06_22-15-50.log:

ERROR service=llm providerID=openai modelID=gpt-5.4 ... error={"error":{"code":"UNKNOWN_CERTIFICATE_VERIFICATION_ERROR","path":"https://chatgpt.com/backend-api/codex/responses","errno":0}} stream error
ERROR service=session.processor error=unknown certificate verification error process

Additional debugging notes

  • Desktop parent process had:
    • BUN_OPTIONS=--use-system-ca
  • Desktop sidecar (opencode-cli serve) also inherited the expected environment after cleanup, including tests with:
    • NODE_USE_SYSTEM_CA=1
    • no stale /etc/ssl/cert.pem overrides
    • and later an explicit CA PEM bundle generated from macOS keychains
  • Despite that, 1.3.17 app still failed.
  • The same machine could still do TLS to chatgpt.com using system tools.
  • After rolling CLI back to 1.3.16, the CLI worked again.

Operating System

macOS 26.4 (Apple Silicon)

Terminal

zsh

Activity

  1. github-actions
    assigned
    iamdavidhill
    on Apr 6, 2026
  2. github-actions
    added
    coreAnything pertaining to core functionality of the application (opencode server stuff)
    webRelates to opencode on web / desktop
    on Apr 6, 2026

  3. github-actions commented on Apr 6, 2026

    @github-actions
    github-actionsBot
    on Apr 6, 2026 – with GitHub Actions
    Contributor

    This issue might be a duplicate of existing issues. Please check:

    If your issue is distinct (specifically a 1.3.17 regression with a proxy/Clash setup on macOS), please confirm that and a maintainer can separate it.

  4. atongrun commented on Apr 6, 2026

    @atongrun
    atongrun
    on Apr 6, 2026
    Author

    Additional observation after more testing on macOS:

    This does not look like a 100% deterministic failure.

    With the CLI switched back to 1.3.17, I observed:

    • first request: unknown certificate verification error
    • second request: unknown certificate verification error
    • third request: succeeded normally

    So the problem appears to be intermittent rather than a hard permanent failure.

    That makes it look more like an unstable TLS / certificate verification path under the current runtime + proxy/network conditions, rather than a simple always-broken configuration.

    In other words:

    • the issue still seems real on macOS + 1.3.17
    • but it may require retries to reproduce reliably
    • and successful retries suggest the endpoint / account / base network path is not permanently broken

    This may be useful if you're trying to narrow it down to a regression in runtime TLS handling, connection reuse, proxy interaction, or certificate chain selection.

  5. atongrun commented on Apr 6, 2026

    @atongrun
    atongrun
    on Apr 6, 2026
    Author

    Correction / update after further testing:

    This now looks less like a 1.3.17-only regression and more like an intermittent macOS TLS/certificate verification problem across multiple versions in this proxy-dependent setup.

    Additional observation:

    • 1.3.17: intermittent unknown certificate verification error, but retries can eventually succeed
    • 1.3.16: CLI could appear more stable in one round of testing, but that was not enough to conclude the issue was fully gone
    • 1.3.6: also shows the same intermittent behavior

    So the more accurate summary is:

    • this is probably not strictly a 1.3.17 regression
    • it is still reproducible on macOS in a Clash/proxy-dependent environment
    • failures are intermittent, and retries may succeed

    That suggests something closer to unstable TLS verification / proxy interaction / connection reuse behavior rather than a single permanently broken release.

  6. atongrun
    changed the title [-]macOS 1.3.17 regression: UNKNOWN_CERTIFICATE_VERIFICATION_ERROR for OpenAI/Codex endpoint, 1.3.16 CLI works[/-] [+]macOS intermittent UNKNOWN_CERTIFICATE_VERIFICATION_ERROR for OpenAI/Codex endpoint under proxy conditions[/+] on Apr 6, 2026

  7. yaosongding commented on Apr 8, 2026

    @yaosongding
    yaosongding
    on Apr 8, 2026

    I get the same problem, and I saw this comment, I disconnected my tailscale and it's fixed! Still don't understand the root cause but I decided to move on.

  8. thdxr
    removed
    webRelates to opencode on web / desktop
    coreAnything pertaining to core functionality of the application (opencode server stuff)
    on May 3, 2026

  9. leowio commented on May 25, 2026

    @leowio
    leowio
    on May 25, 2026

    This issue exists on Arch Linux too

  10. github-actions commented on Jul 25, 2026

    @github-actions
    github-actionsBot
    on Jul 25, 2026 – with GitHub Actions
    Contributor

    To stay organized issues are automatically closed after 60 days of no activity. If the issue is still relevant please open a new one.

  11. github-actions
    closed this as not plannedon Jul 25, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

Labels

No labels
No labels

Type

No type

Projects

No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions