WorkBuddy GPT & Gemini Secure Bridge

Problem

When engineers want to connect personal Codex/ChatGPT and Antigravity/Gemini subscriptions to WorkBuddy, the risk is not only connectivity. A local proxy may be exposed beyond loopback, WorkBuddy may cache a stale system proxy, a model may look available but fail streaming or tool calls, and manual model entries can be overwritten. This skill treats the integration as an auditable change rather than a blind config write.

How It Works

It starts with audit, checking whether CLIProxyAPI listens only on 127.0.0.1, reviewing models.json, counting OAuth files, and detecting workbuddy_stale_system_proxy. If a stale proxy is found, it asks for a full WorkBuddy restart instead of editing HTTP_PROXY. Deployment keeps the service bound to loopback, disables remote administration, creates an independent local client key, and writes a timestamped backup before changes. Authorization uses the native CLIProxyAPI browser OAuth flow and does not write provider tokens into WorkBuddy. Synchronization reads live /v1/models, probes text, SSE streaming, tools, image input, and reasoning controls, keeps only models that pass basic probes, and demotes failed optional capabilities to false. It then validates at least one GPT and one Gemini model with real text calls, reporting provider, model IDs, capability results, and backup paths.

Boundaries

This is for user-owned, authorized subscriptions on a local machine. It is not for exposing remote services, bypassing subscription terms, or exporting account credentials. If CLIProxyAPI is unreachable, recover the existing service first. Re-authorize only when provider auth is missing or failing. Any unprobed or unvalidated capability should be treated as unverified.