Outbound port 443 replaces an inbound MCP listener, not the data path
tunnel-client maintains outbound HTTPS to api.openai.com on port 443 and polls for work addressed to one tunnel ID. When ChatGPT, Codex, the Responses API, or AgentKit calls a tool, OpenAI queues the JSON-RPC request. The daemon retrieves it, forwards it to a private Streamable HTTP, stdio, or in-memory MCP server, then posts the response back. Your MCP listener needs no public URL or inbound firewall rule.
That network design does not make the request local. The architecture guide says tool arguments, responses, stream events, and applicable authentication artifacts cross the OpenAI product runtime and tunnel service. Only the final client-to-MCP hop stays inside your network. Static extra headers and MCP-side mutual TLS can protect that last HTTP hop, but strict-local-auth is explicitly unsupported. Use direct local MCP configuration when every bearer token or auth artifact must avoid OpenAI.
The 5-second npm result never compiled the Go client
Our lab ran the repository's npm surface because a root package.json is present. Installation finished in 5 seconds, added 0 packages, and left 16 MB on disk. That manifest pins Node and pnpm versions but defines no scripts or dependencies. The harness therefore found no build target and no test target. Npm audit reported 0 known vulnerabilities in the empty npm dependency tree.
The application itself is written primarily in Go. Its README tells contributors to use go build ./... and go test ./..., or Make targets that also prepare the embedded admin interface and stamp version metadata. We did not run those commands, so this review makes no claim that the Go code builds or that its tests pass. A release binary is a more honest first-use path than treating the npm result as source validation.
What happened when we ran it
Our sandbox checkout at commit 1952115 held 671 files, roughly 156,259 source lines, and 10.6 MB before installation. The npm install succeeded in 5 seconds with 0 packages added. Build and tests were skipped because neither npm target existed. The audit found 0 critical, high, moderate, or low known vulnerabilities in that npm scope.
The scan found 2 CI workflow files and a Dockerfile, but no directory named tests. Go commonly keeps _test.go files beside production code, and this repository has that layout, so the directory signal does not mean there are no Go tests. It means our Node-oriented harness did not exercise them. We also did not create a tunnel, send MCP traffic, or test ChatGPT connector behavior in the supplied run.
Two keys and three permissions separate runtime use from administration
A basic deployment needs a provisioned tunnel ID, one runtime API key, and an MCP target. The runtime principal needs Tunnels Read plus Use. Tunnel managers add Manage, while list, create, update, and delete commands use a separate OpenAI admin key. The documentation repeatedly warns against putting that admin key into the long-lived daemon, which is the right separation for a service sitting beside internal tools.
Configuration still has enough edges to reward a dry run. tunnel-client init writes a profile, and doctor --explain checks it before startup. The process exposes /healthz, /readyz, /metrics, and /ui, bound to loopback by default. Those endpoints tell you about the local process, MCP reachability, and polling state. They cannot prove that a particular ChatGPT workspace has the correct organization context or will accept connector discovery.
One tunnel ID cannot safely front two stdio clients
The README supports only 1 active tunnel-client per tunnel ID when the MCP binding uses a stdio command. Each client would launch its own child process, so initialization and later calls could land on different children. That rules out overlapping restarts and ordinary active-active replicas for this transport. Stop the old process first, use distinct tunnel IDs, or choose a deployment whose MCP state can handle the documented multi-replica behavior.
Operational options are otherwise thoughtful. The repository documents a foreground process, Codex-managed runtimes, Docker, Kubernetes sidecars or dedicated pods, and VM services. Health and metrics make the daemon observable, and v0.0.14 adds a privacy-safe startup catalog digest for comparing equivalent replicas. The release notes also say that matching digests do not prove health, polling, routing, shared-state safety, or later convergence. That is a useful limit, not fine print.
Version 0.0.14 still has hosted connector failures to diagnose
Release v0.0.14 was published on September 1, 2026 with multi-replica OAuth work, redirect restrictions, secret redaction changes, and support evidence. Yet issue 71's connector-creation report uses the official v0.0.14 embedded stub on Windows and records green local health and readiness while ChatGPT rejects both no-auth and OAuth setup at different hosted steps. The local tunnel forwarded responses, but the connector was never created.
Issue 60 describes another boundary: a ChatGPT Pro workspace saw every real tool call rejected with 401 tunnel_active_organization_required before the private MCP server received anything. Neither report proves a universal failure. Both show why /readyz is necessary but insufficient. Your acceptance test should create the connector in the intended workspace, list tools, invoke one harmless tool, and confirm that the private server received it.
The September 19 push shows maintenance, not finished compatibility
GitHub showed 425 stars and 11 combined open issues and pull requests on September 19, 2026. The latest push was that same day, while the latest tagged release remained v0.0.14 from September 1. Recent reports and closures cover managed Cloudflare credentials, connector discovery, OAuth, antivirus warnings, Gatekeeper, Windows signing, stdio recovery, and support-archive redaction. This is an actively changing integration surface.
For the exact OpenAI tunnel path, tunnel-client is the obvious project to trial because it owns the product-specific control plane, permissions, diagnostics, and release artifacts. It is less attractive as a general tunneling tool or a privacy boundary. Pin the release, follow the matching documentation, keep the runtime key narrow, and test the hosted product end to end. A green daemon without a successful tool call is only half a deployment.