bug(cli): mTLS client certs not loaded from gateway config dir in 0.0.83

[zanetworker]

Summary

The 0.0.83 CLI does not load mTLS client certificates from ~/.config/openshell/gateways/<name>/mtls/ when connecting to a local mTLS-enabled gateway. The gateway correctly requests client auth (CertificateRequest), but the CLI responds with no certificate, causing CertificateRequired fatal alert.

Environment

• CLI: openshell 0.0.83
• Gateway: openshell-gateway 0.0.83 (via brew, mTLS + podman driver)
• OS: macOS (Apple Silicon)
• Gateway registered via: openshell gateway add https://127.0.0.1:17670 --local --name openshell

Reproduction

# 1. Clean install 0.0.83 via brew
brew services restart openshell

# 2. Register gateway
openshell gateway add https://127.0.0.1:17670 --local --name openshell

# 3. Verify certs exist
ls ~/.config/openshell/gateways/openshell/mtls/
# tls.crt  tls.key  ca.crt

# 4. Verify certs work via curl
curl -sk --cert ~/.config/openshell/gateways/openshell/mtls/tls.crt \
     --key ~/.config/openshell/gateways/openshell/mtls/tls.key \
     https://127.0.0.1:17670/healthz
# Success (exit 0)

# 5. CLI fails
openshell provider list
# Error: received fatal alert: CertificateRequired

Debug Output

RUST_LOG=debug openshell provider list 2>&1 | grep -i cert

Key line:

DEBUG rustls::client::common: Client auth requested but no cert/sigscheme available

The rustls TLS client has no certificate configured even though the certs exist at the expected path.

Expected Behavior

The CLI should load tls.crt and tls.key from ~/.config/openshell/gateways/<name>/mtls/ and present them during the TLS handshake when auth_mode is mtls in the gateway metadata.

Workaround

None found. The plaintext gateway (--disable-tls) works for the CLI but the supervisor in 0.0.83 requires sandbox JWT auth, which is only minted by the mTLS/OIDC gateway.

[zanetworker]

Update: Root cause identified — NOT an mTLS client cert bug

The initial diagnosis was wrong. The mTLS cert loading failure was caused by OPENSHELL_GATEWAY_INSECURE=true being set in the shell environment, which causes build_insecure_rustls_config() to call .with_no_client_auth(), skipping client certs entirely. That's working as designed (though arguably the insecure path should still present client identity while skipping server verification).

Actual root cause: supervisor cannot access container filesystem via /proc on podman/macOS

With OPENSHELL_GATEWAY_INSECURE unset, the mTLS gateway works. But CONNECT requests are still denied because the supervisor cannot resolve binary identities:

Cannot access container filesystem for symlink resolution: 
  path=/usr/local/bin/node 
  container_path=/proc/36/root/usr/local/bin/node 
  pid=36 
  error=No such file or directory (os error 2)

Since require_binary_identity=true (the default), the OPA policy needs to match the requesting binary. But /proc/<pid>/root/ is inaccessible in the podman-on-macOS VM topology, so binary resolution fails for every process. No binary matches → every CONNECT is denied.

This affects ALL egress from sandboxes on the podman driver on macOS, not just Vertex AI.

Environment

• macOS (Apple Silicon), podman machine
• openshell 0.0.83, openshell-gateway 0.0.83, supervisor 0.0.83
• Gateway: mTLS + podman driver via homebrew service

Suggested fix

Either:

1. Fall back to allowing endpoint-only matching when /proc/<pid>/root/ is inaccessible (degrade gracefully instead of fail-closed)
2. Or document that podman-on-macOS requires require_binary_identity=false in the runtime config

[zanetworker]

Closing — this was not an upstream bug. Root causes were local misconfigurations:

1. OPENSHELL_GATEWAY_INSECURE=true in shell env caused the CLI to take the insecure TLS path (build_insecure_rustls_config() → .with_no_client_auth()), which skips mTLS client certificates entirely. Unsetting the env var restored mTLS connectivity.

2. Policy --binary claude uses short name but the OPA policy matches against full /proc/<pid>/exe paths. Claude Code's HTTP requests are made by /usr/bin/node, not /usr/local/bin/claude. Using --binary /usr/local/bin/claude --binary /usr/bin/node resolved the CONNECT denial.

Minor UX suggestion (not a bug): --gateway-insecure semantically means "skip server cert verification" but it also drops client identity. It might be worth having the insecure path still load and present client certs while only disabling server verification. This would prevent the confusing CertificateRequired error when users set OPENSHELL_GATEWAY_INSECURE=true for convenience.

Apologies for the noise.