Lynx combines a local multi-client MCP Gateway with a capability-driven bring-your-own-CLI Agents runtime, workspace routing, permission controls, adaptive CLI verification, activity inspection, real terminals, developer automation, and a hardened keyboard-friendly renderer with recoverable error states. This reference describes the capabilities implemented in the current v0.5.8 codebase.
Remote or local MCP applications connect to one authenticated Lynx gateway. Lynx decides whether the client is accepted, which projects it can see, which local operations its scope permits, whether an operation needs local approval, and which configured provider credentials can be used.
ChatGPT, OpenCode, Gemini, IDE, CLI, or another compatible application.
DCR + Authorization Code + PKCE + Lynx Accept / Reject gate.
Connection state, local capability scope, workspace grants, request ceilings.
Workspace, files, commands, Git, activity, integrations, provisioning.
Selected workspace plus GitHub, Vercel, Supabase, Neon, or Firebase.
Lynx Agents uses coding CLIs already installed and authenticated on your computer. Lynx provides discovery, role routing, process/session control, task state, review loops, and terminals without embedding another LLM.
Rescan PATH plus Windows per-user native/npm/WinGet/pnpm/Scoop/Bun locations, probe versions/readiness/models, automatically rescan after installs or interactive CLI terminal exit, and open detected CLIs in real terminal sessions. Teams also exposes Refresh CLIs & models.
Claude Code, Codex CLI, OpenCode, Gemini CLI, Kiro CLI, and GitHub Copilot CLI keep validated optimized fast paths. Custom executables can use Verify adaptive to prove a generic headless, stdin/stdout, callback-PTY, or rendered-nonce transport without adding product-specific Lynx code.
Persist Thinker / Lead, Planner, Implementer, Tester, and Reviewer assignments plus runtime-discovered models where the CLI exposes them. Teams distinguishes credentialed/verified models from unverified/unavailable entries, keeps CLI default available, correlates OpenCode models with its authenticated providers, and discovers authenticated Claude choices through Claude's own screen-reader /model UI without sending an AI prompt or using a Lynx model catalog.
Run a deterministic local pipeline with exact prompt visibility, PID/executable details, live CLI output, model/limit telemetry, testing, review, and bounded revision cycles.
Verified Level 1 headless and Level 2 stdin/stdout paths run as hidden processes. Level 3 uses a task-scoped local lynx-emit callback; Level 4 reconstructs a hidden PTY through headless xterm and extracts a cryptographic nonce block. Interactive xterm remains Level 5 fallback.
Safe mode is the default. Autonomous mode requires native confirmation before supported mutable roles use documented non-interactive permission behavior.
Every OAuth registration becomes a separate Lynx client identity. New clients cannot use MCP tools until accepted locally. Display names and logos help recognition, while permissions bind to the internal OAuth client identity rather than the displayed application name.
New applications appear as pending with application/redirect context. You choose Accept or Reject before usable authorization is issued.
Inspect authorized/connected/blocked/revoked clients, active sessions, active requests, last seen state, runtime version, and workspace usage.
Disconnect current sessions without deleting authorization, revoke tokens to require authorization again, or block a known client identity.
Control whether new OAuth clients are allowed to enter the authorization flow while existing accepted clients continue operating.
Clients authorized before v0.4.0 remain previously authorized by default. Optional legacy re-approval can revoke them and require one new Accept decision.
Immediately closes active sessions and returns HTTP 423 for MCP traffic without deleting saved workspaces, client registrations, or provider credentials.
Lynx can save multiple local project roots. Every MCP session uses one selected workspace at a time, and project visibility is filtered before tools such as list_workspaces or select_workspace return data.
| Mode | Who can see it | Behavior |
|---|---|---|
| Shared | Every accepted client | The workspace is visible to any authorized Lynx client and can be selected per MCP session. |
| Restricted | Explicit client grants | Only chosen client identities receive the workspace name/path and may select it. |
| Private | Explicit client grants | No automatic visibility. A client must be explicitly included before the workspace exists from that client's perspective. |
Scope applies to local workspace mutations. Cloud integrations are intentionally Lynx-wide capabilities for accepted clients and are governed separately by the global integration approval policy.
| Preset | Read/search | Local writes / commands / Git mutations | Delete path | Integrations |
|---|---|---|---|---|
| Read only | Allowed | Blocked | Blocked | Available via global policy |
| Developer | Allowed | Allowed | Blocked | Available via global policy |
| Full | Allowed | Allowed | Allowed subject to policy | Available via global policy |
Lynx separates hard access boundaries from interactive approval. A request must first pass client authorization, workspace access, capability scope, lockdown, and request-limit checks. Approval never expands a denied scope.
Risky local writes, commands, Git/network actions, and integration mutations can enter the local Allow / Reject queue.
Lynx automatically passes its own local approval gate for operations that already passed hard scope/security checks.
Choose whether accepted clients can use connected integrations without Lynx permission prompts or whether integration mutations require local review.
Configurable concurrent MCP POST requests and requests per minute stop runaway agent loops before tool execution.
UI presets support 2/4/8/16/32 concurrent requests and 60/120/240/600/1200 requests per minute.
ChatGPT, Gemini, OpenCode, IDEs, or CLIs may enforce their own confirmation UX independently of Lynx.
Lynx also supplies client-aware initialization instructions and lynx_info, which can report current scope, visible workspaces, integration state, request limits, security rules, and allowed tool categories without returning provider credentials.
Provider credentials can be configured in the Lynx Integrations tab or remotely through a secure one-time Lynx setup link, validated before being accepted, encrypted locally with Electron safeStorage, and decrypted only inside the Electron main process when needed.
Create repositories, publish the selected workspace safely, and use constrained GitHub REST access without embedding the PAT in a Git remote URL.
Create projects, configure environment variables, trigger Git-backed deployments, inspect deployments, and use additional supported REST operations.
Create/get projects and access the Management API while keeping generated database secrets and service credentials inside Lynx.
Create Postgres projects and branches, call the Neon API, and keep database connection URIs encrypted/local.
Use encrypted service-account JSON to obtain short-lived Google OAuth tokens, manage Firebase projects, Hosting sites, Firestore databases, and allowlisted Firebase APIs.
provision_workspace_stack can publish a workspace to GitHub, optionally provision Supabase or Neon, transfer required secrets internally, and deploy with Vercel.
integration_create_setup_link creates a random one-time 10-minute HTTPS page so a phone/browser can submit a credential directly to Lynx without sending it through chat. A per-client Allow credentials from this client toggle can additionally expose integration_save_credential for deliberate one-way chat/client provisioning; it is off by default. Credentials are never readable back through MCP and secret arguments are redacted from Activity.Lynx records only activity observable at its own MCP/protocol boundary. It does not expose hidden model reasoning. Activity is attributable to client identity, session, workspace, tool, status, and bounded request/response metadata.
Activity can include client ID/name/version, MCP session ID, workspace ID/name/path, method/tool, request ID, protocol version, timing, status, and bounded payload details.
The Activity page persists recent records across app restarts, groups calls by client + MCP session + workspace, supports free-text search/filters, and can export a sanitized JSON view that omits payloads, paths, and client/session identifiers.
Connection requests, Accept/Reject, revoke/block, workspace grants, policy changes, request-limit denials, pairing changes, and lockdown events are logged as security activity.
Connection, approval/request, and Agents task notifications can focus/open Lynx, switch to the owning Gateway/Agents surface, navigate to the exact tab, scroll to the matching item when present, and briefly highlight it. The preload bridge buffers the destination until the renderer subscribes so a startup race cannot drop the route.
The centralized notification manager tracks categories/IDs, prevents duplicate popups, and closes tracked notifications when disabled. Gateway/Agents and the relevant Activity, Connections, and Tasks items expose live numeric pending badges.
Authorization headers and provider secrets are excluded/redacted from Activity. Generic provider request bodies and sensitive error responses are protected.
Lynx is designed to stay useful as a background Windows gateway, not only while its main window is open.
Closing the window hides Lynx while the bridge/tunnel continues. Installed Windows builds register a hidden background launch at user login; the tray can reopen the UI, stop the bridge, or quit Lynx.
The desired bridge-running state is persisted. A background watchdog probes the local MCP health endpoint and public tunnel, retries repeated failures with backoff, and re-checks after Windows resumes from sleep. Review approvals can remain pending even when no main window exists.
Installed builds check GitHub Releases and download updates in the background. After download, Lynx waits until MCP requests, pending approvals, and Agents tasks are idle, preserves the desired bridge-running state, then installs and restarts automatically. A manual install-now control remains only as an optional fallback.
ngrok is embedded and can use an encrypted authtoken. localhost.run provides an SSH-based alternative. Auto can select/fallback between supported providers.
Workspace registry, appearance, approval/notification settings, OAuth client state, provider credentials, scopes, limits, integration configuration, and the newest 500 bounded Activity records remain local.
About can open a prefilled GitHub issue draft with optional safe diagnostics. A user-selected screenshot can be copied to the clipboard for manual paste; Lynx never auto-submits the issue.
The desktop UI uses persistent light/dark appearance, collapsible navigation, dedicated Gateway and Agents mode navigation, and workspace/activity management views.
CLI discovery, optimized known adapters, verified adaptive custom CLIs, learned executable fingerprints, persisted role teams, task orchestration, PTY/headless transports, dedicated Agents activity, and Safe / Autonomous settings operate alongside the MCP Gateway.
Lynx adds strong local routing, authentication, policy, credential, and approval boundaries, but it does not claim to be an operating-system sandbox or enterprise multi-user IAM product.
run_command executes with the current Windows user's normal permissions after Lynx policy approval. Review Requests is the safer default unless you intentionally want autonomous local execution.