源码快照 @ 2026-09-02 (source-only, 剔除非源码素材)

This commit is contained in:
agent-radar
2026-09-02 01:05:41 +08:00
commit 04bac1f6e2
2200 changed files with 489415 additions and 0 deletions
@@ -0,0 +1,223 @@
---
title: "OpenWork MCP Gateway"
sidebarTitle: "Overview"
description: "The OpenWork MCP Gateway is one hosted endpoint that brings your organization's skills, plugins, and connections into Claude Code, Codex, Claude Desktop, Cursor, VS Code, or any MCP client."
---
import { OpenWorkConnectInstaller } from "/snippets/openwork-connect-installer.jsx";
The OpenWork MCP Gateway is one MCP endpoint for everything your organization has made available to you: skills, plugins, workflows, and connections. Instead of configuring one MCP server per service, your agent connects to the gateway once and discovers capabilities on demand. The public hosted endpoint is:
```text
https://api.openworklabs.com/mcp/agent
```
This guide is for connecting an external MCP client to OpenWork. To connect
Gmail, calendar, Drive, Slack, Notion, Linear, or another service inside the
OpenWork desktop app, use
[Connect your services](/start-here/connect-your-stack/connect-services).
Your client opens a browser, you sign in to OpenWork, choose the organization to authorize, and the client stores the OAuth token for that organization.
`app.openworklabs.com/api/den` is an internal same-origin desktop proxy used by OpenWork first-party flows. Do not paste it into external MCP clients.
<OpenWorkConnectInstaller />
## Set up your client
Step-by-step guides for every client:
<CardGroup cols={3}>
<Card title="OpenCode" href="/model-context-protocol/opencode" />
<Card title="Claude Code" href="/model-context-protocol/claude-code" />
<Card title="Codex" href="/model-context-protocol/codex" />
<Card title="Claude Desktop" href="/model-context-protocol/claude-desktop" />
<Card title="ChatGPT" href="/model-context-protocol/chatgpt" />
<Card title="Cursor" href="/model-context-protocol/cursor" />
<Card title="VS Code" href="/model-context-protocol/vs-code" />
<Card title="Windsurf" href="/model-context-protocol/windsurf" />
<Card title="Zed" href="/model-context-protocol/zed" />
<Card title="Gemini CLI" href="/model-context-protocol/gemini-cli" />
</CardGroup>
## In the OpenWork desktop app
If you use the OpenWork desktop app, there is no MCP endpoint to configure.
When you sign in, the app injects OpenWork Connect with access scoped to your
active organization and refreshes that first-party access automatically. Use
`Settings` > `Connect` to sign in to the services available to you.
## Client support status
| Client | Status | Notes | Guide |
| --- | --- | --- | --- |
| OpenCode | Verified | Native remote MCP OAuth passed end-to-end implementation testing. | [OpenWork MCP for OpenCode](/model-context-protocol/opencode) |
| Codex | Setup only | Add/login/reconnect steps are below; native remote MCP OAuth must be rerun on this exact branch before Codex is marked verified. | [OpenWork MCP for Codex](/model-context-protocol/codex) |
| Cursor | Setup only | Cursor Web/Agents use an HTTPS OAuth callback. Cursor Desktop OAuth uses `cursor://anysphere.cursor-mcp/oauth/callback`, which OpenWork accepts through an exact private-use allowlist with PKCE S256 enforced. Native proof is not complete. | [OpenWork MCP for Cursor](/model-context-protocol/cursor) |
| ChatGPT Desktop | Setup only | Setup guide only; use ChatGPT `Settings > MCP servers`. Native proof is not complete. | [OpenWork MCP for ChatGPT](/model-context-protocol/chatgpt) |
| Claude Code | Setup only | Setup guide only; native proof is not complete. | [OpenWork MCP for Claude Code](/model-context-protocol/claude-code) |
| Claude Desktop | Setup only | Setup guide only; native proof is not complete. | [OpenWork MCP for Claude Desktop](/model-context-protocol/claude-desktop) |
| VS Code | Setup only | Setup guide only; native proof is not complete. | [OpenWork MCP for VS Code](/model-context-protocol/vs-code) |
| Windsurf | Setup only | Setup guide only via mcp-remote; native proof is not complete. | [OpenWork MCP for Windsurf](/model-context-protocol/windsurf) |
| Zed | Setup only | Setup guide only via mcp-remote; native proof is not complete. | [OpenWork MCP for Zed](/model-context-protocol/zed) |
| Gemini CLI | Setup only | Setup guide only; native proof is not complete. | [OpenWork MCP for Gemini CLI](/model-context-protocol/gemini-cli) |
| Any client | Setup only | Use only with clients that support remote Streamable HTTP MCP servers and OAuth. | — |
## OpenCode setup
Add this MCP entry to your OpenCode config:
```json
{
"mcp": {
"openwork": {
"type": "remote",
"enabled": true,
"url": "https://api.openworklabs.com/mcp/agent",
"oauth": {}
}
}
}
```
Then authenticate:
```sh
opencode mcp auth openwork
```
If OpenCode runs on a remote machine but the browser opens locally, follow
[Connect OpenWork MCP from a remote machine](/cloud/run-in-the-cloud/connect-openwork-mcp-remote-machine).
To reconnect or switch organizations, remove the old token and authenticate again:
```sh
opencode mcp logout openwork
opencode mcp auth openwork
```
Full guide: [OpenWork MCP for OpenCode](/model-context-protocol/opencode).
## Codex setup
Codex is setup-only for this PR until its native OAuth flow is rerun on this exact branch.
Add OpenWork, then log in:
```sh
codex mcp add openwork --url https://api.openworklabs.com/mcp/agent
codex mcp login openwork
```
To reconnect or switch organizations, log out and log in again:
```sh
codex mcp logout openwork
codex mcp login openwork
```
Full guide: [OpenWork MCP for Codex](/model-context-protocol/codex).
## Cursor setup-only guide
Paste the OpenWork Connect endpoint where Cursor asks for the remote MCP server URL, then start OAuth from Cursor's connection prompt:
```text
https://api.openworklabs.com/mcp/agent
```
Cursor Web/Agents use an HTTPS OAuth callback. Cursor Desktop OAuth uses the private-use callback `cursor://anysphere.cursor-mcp/oauth/callback`, which OpenWork accepts through an exact allowlist with PKCE S256 enforced, so intercepted authorization codes cannot be redeemed without the code verifier.
Full guide: [OpenWork MCP for Cursor](/model-context-protocol/cursor).
## ChatGPT setup-only guide
Open ChatGPT `Settings > MCP servers` ([open settings](https://chatgpt.com/#settings/Connectors)), paste the OpenWork Connect endpoint, and start OAuth from ChatGPT's connection prompt:
```text
https://api.openworklabs.com/mcp/agent
```
Full guide: [OpenWork MCP for ChatGPT](/model-context-protocol/chatgpt).
## Organization selection
The organization you choose in the browser is pinned into the token. Changing the active organization in OpenWork later does not change an external client's existing token. Use the logout/auth or logout/login reconnect commands above when you need a different organization.
## What you can ask the agent
Once connected, your agent can use OpenWork capabilities from plain English in the composer. These flows are exercised end to end against a live OpenWork Cloud deployment:
- **Check your cloud identity** — "Which OpenWork Cloud organization am I
connected to?" The agent reports the organization, your account, and your
role.
- **Invite teammates** — "Add omar@example.com to my organization." The agent
sends the invitation, updates the allowed email domains when needed, and
surfaces seat-limit billing rules instead of failing silently.
- **Manage teams** — "Assign Priya to the Sales team." Works for active
members; the agent explains when someone still has a pending invitation.
- **Share skills with your org** — "Create a skill that writes weekly status
reports and share it with my whole organization." The agent writes the
skill inside a plugin, adds the plugin to a Collection, and grants the
Collection org-wide — teammates find the assigned skill in `Settings > Library`.
Org policy still applies: invitations respect seat limits and domain rules, and resource access follows organization membership, roles, policies, and exposure allowlists.
## OAuth and protocol details
OpenWork Connect is a remote Streamable HTTP MCP server with OAuth:
- The protected resource is exactly `https://api.openworklabs.com/mcp/agent`.
- Clients discover OAuth metadata with RFC9728 protected-resource discovery.
- The authorization server and browser sign-in origin is `https://app.openworklabs.com/api/auth`.
- OAuth authorize and token requests must include exactly one `resource` value: `https://api.openworklabs.com/mcp/agent`.
- Clients that need registration use dynamic client registration as a fallback during discovery.
- PKCE is required for public/dynamic clients, and only the `S256` code challenge method is supported.
- Redirect URIs must be HTTPS callbacks or HTTP loopback callbacks such as `http://127.0.0.1:<port>/callback`. Private-use callback schemes are not accepted for public OAuth clients, except exact allowlisted callbacks for known native clients — currently Cursor Desktop's `cursor://anysphere.cursor-mcp/oauth/callback` — with PKCE S256 enforced.
## Token lifetime and refresh
Clients normally refresh automatically. The values matter when diagnosing reconnects:
- Public OAuth access tokens are JWTs signed and validated with EdDSA. The issuer is exactly `https://app.openworklabs.com/api/auth`, the audience is exactly `https://api.openworklabs.com/mcp/agent`, and access tokens expire after 45 minutes.
- Refresh tokens are opaque rotating grants with a 30-day inactivity window and a 30-second rotation overlap for near-simultaneous refreshes.
- Each refresh revokes the previous refresh grant; because OpenWork stores only token hashes, a replay during the overlap can issue another successor instead of returning prior plaintext.
- Successor grants remain normal rotating grants. If an old refresh grant is replayed after the overlap, expired, or revoked, the client may receive `invalid_grant` and the client/user refresh-token family is revoked. Reconnect by logging out of the MCP entry and authenticating again.
- Access is rechecked against the active OpenWork session and organization membership, so removing a member or revoking the session cuts off MCP access.
## What the gateway exposes
Instead of flooding your client with hundreds of tool definitions, the gateway keeps the tool list small and constant. `/mcp/agent` exposes two discovery tools:
- `search_capabilities` searches the capabilities available to the signed-in member.
- `execute_capability` runs an exact capability name returned by `search_capabilities`.
Search can include OpenWork Cloud resources such as skills, plugins, connectors, Collections, workers, members, roles, teams, model providers, and org-connected external MCP tools when those capabilities are enabled and shared with the member.
Availability is governed by organization membership, role, policy, and exposure allowlists. It intentionally does not expose authentication internals, admin-only system routes, webhooks, API-key creation or deletion, or credential-returning endpoints.
## MCP Apps
Some gateway results come back as MCP Apps: rich, interactive UI rendered from a tool result instead of plain text — great for dynamic interfaces like a created-skill confirmation card or a workflow result view. OpenWork implements the standard [MCP Apps extension](https://modelcontextprotocol.io/docs/extensions/apps) (`ui://` resources declared on tools), so first-party OpenWork apps render in any MCP client that supports the extension, and fall back to readable text everywhere else.
<Frame>
![The skill-created MCP App rendering in the OpenWork desktop app after a create-skill request](/images/skill-created-mcp-app-card.png)
</Frame>
MCP Apps from third-party providers — apps shipped by an MCP server your organization added as a connector — currently render in the OpenWork desktop app, where connectors are enabled as a native MCP Apps preview per organization. Rendering third-party apps in external clients requires exposing that connector as a full MCP server, an option that is planned but not available yet.
## Troubleshooting
- **401 missing or invalid token**: run the client's auth/login command again. Confirm the client points to `https://api.openworklabs.com/mcp/agent`.
- **403 membership or scope error**: confirm you selected the right organization and still have membership and required permissions there.
- **`invalid_grant`**: the refresh grant was expired, revoked, or replayed after the 30-second rotation overlap. Run logout, then auth/login again.
- **429 rate limit**: wait for the response's `Retry-After` value before retrying.
- **Support requests**: include the response `X-Request-Id` header plus any JSON body MCP `referenceId` or OAuth `reference_id` field so OpenWork support can find the server-side trace.
## Requirements
- An OpenWork Cloud account and organization.
- An MCP client that supports remote Streamable HTTP MCP servers.
- OAuth support in the MCP client, including browser-based authorization.
If your client does not support OAuth for remote MCP servers, it cannot connect to OpenWork Connect yet.
@@ -0,0 +1,54 @@
---
title: "Connect OpenWork MCP from a remote machine"
description: "Authenticate OpenWork Connect for OpenCode on a remote host while using a browser on your local machine"
---
Use this when OpenCode runs on a remote machine, SSH host, or cloud VM, but the OAuth browser opens on your laptop or another local machine. In the commands below, `<server-name>` is the OpenWork MCP name in your OpenCode config, often `openwork`.
## Why remote OAuth times out
During `opencode mcp auth <server-name>`, OpenCode listens for the OAuth redirect on the remote host at:
```text
http://127.0.0.1:19876/mcp/oauth/callback
```
If you open the printed authorization URL in a browser on another machine, that browser resolves `127.0.0.1` to the browser's own machine, not the remote host where OpenCode is listening. The OAuth approval succeeds in the browser, but the callback never reaches OpenCode, so the auth command eventually times out.
## Recommended: open SSH with a local port forward
From the local machine where you will open the browser, start SSH with a loopback-only local port forward and a remote shell:
```sh
ssh -o ExitOnForwardFailure=yes -L 127.0.0.1:19876:127.0.0.1:19876 user@remote-host
```
In that SSH shell on the remote host, run:
```sh
opencode mcp auth <server-name>
```
Open the printed authorization URL in your local browser. Keep the SSH session open until OpenCode reports that authentication succeeded.
The `-L` option makes the local browser's `http://127.0.0.1:19876/...` callback travel through SSH to `127.0.0.1:19876` on the remote host. The callback stays bound to loopback on both machines.
## Optional: add a tunnel from a second terminal
If you are already connected to the remote host in one terminal, keep that terminal for OpenCode and open a second local terminal for the tunnel:
```sh
ssh -N -o ExitOnForwardFailure=yes -L 127.0.0.1:19876:127.0.0.1:19876 user@remote-host
```
Then run `opencode mcp auth <server-name>` in your existing remote shell, open the printed URL locally, and keep both terminals open until authentication succeeds.
## Troubleshooting
- **Timeout or stale URL**: keep the SSH tunnel open, stop the timed-out auth command, run `opencode mcp auth <server-name>` again, and open the new printed URL. OAuth URLs can expire after a failed attempt.
- **Port already occupied**: something on the local or remote machine is already using port `19876`. Stop that process, or configure a different OpenCode `oauth.callbackPort` and update both sides of the SSH forward to use the same port.
- **Custom callback port**: if your OpenCode MCP config sets `oauth.callbackPort`, both forwarding endpoints must match it. For example, with port `34567`, use `-L 127.0.0.1:34567:127.0.0.1:34567`.
- **Cannot reach the remote host**: SSH must be able to reach `user@remote-host` from the local/browser machine. Use the same hostname, bastion, VPN, or SSH config entry you normally use to open a remote shell.
- **No device-code fallback**: OpenCode currently does not have an OAuth device-code flow for MCP, so browser-based auth still needs the loopback callback to reach OpenCode.
Keep the callback on loopback. Do not expose the callback listener on `0.0.0.0`, change it to a public redirect URL, or paste authorization codes into chats or terminals.
@@ -0,0 +1,43 @@
---
title: "Open OpenWork Web in your browser"
description: "Open a full OpenWork instance in your browser with nothing to install"
---
<Warning>
**Hosted access.** OpenWork Web is available to every organization when an OpenWork-hosted deployment explicitly enables it. A platform admin in Den `/admin` can also grant complimentary access to one specific organization while deployment-wide availability is off. Web billing must be configured before an owner or admin can purchase it. It costs **$50 per joined organization member per month**; pending invitations are not billed until they are accepted.
</Warning>
Open `/dashboard/web` to see the price, billable member quantity, expected monthly total, and purchase action. Access opens only after the organization's subscription is confirmed.
## Who can use it
Every joined member can see OpenWork Web when the hosted deployment offers it. An organization owner or admin purchases the subscription; all joined members receive access after it becomes active.
Self-hosted deployments do not show OpenWork Web by default: a missing or false `DEN_OPENWORK_WEB_ENABLED` value fails closed unless a platform admin in Den `/admin` has explicitly granted complimentary access to that organization. If you use an OpenWork-hosted organization and do not see it in the sidebar, email [team@openworklabs.com](mailto:team@openworklabs.com) so the deployment configuration or organization grant can be checked.
## Open OpenWork Web
1. Sign in to your organization dashboard.
2. Click `OpenWork Web` in the sidebar.
3. If prompted, purchase OpenWork Web and wait for the subscription to be confirmed.
4. Click `Open OpenWork Web`.
<Frame>
![The OpenWork Web page in the organization dashboard with the Open OpenWork Web button](/images/cloud-openwork-web.png)
</Frame>
You are now looking at the full OpenWork interface in your browser.
<Frame>
![OpenWork Web open in a browser tab showing the full OpenWork interface](/images/openwork-web-browser-tab.png)
</Frame>
## Sleep and persistence
The hosted instance sleeps when it is idle and wakes when you open it again. Files in the workspace persist across sleep, so you can close the tab and come back later without losing your work.
## Early-access limitation
During early access, the instance URL is itself the credential. Do not share it, paste it into public chats, or publish it anywhere public.
If you accidentally share the URL, ask an OpenWork admin for help.
@@ -0,0 +1,37 @@
---
title: "OpenWork Web"
description: "Run a full OpenWork workspace in the browser, hosted by OpenWork"
---
<Warning>
**Hosted access.** OpenWork Web is available to every organization when an OpenWork-hosted deployment explicitly enables it. A platform admin in Den `/admin` can also grant complimentary access to one specific organization while deployment-wide availability is off. Web billing must be configured before an owner or admin can purchase it. It costs **$50 per joined organization member per month**; pending invitations are not billed until they are accepted.
</Warning>
OpenWork Web gives your team a full OpenWork workspace in the browser, hosted and managed for you — nothing to install. An organization owner or admin can purchase it directly from the organization dashboard.
## Deploy a hosted workspace
1. Open your org dashboard and go to `Shared Workspace`.
2. Click `Add workspace`.
3. Wait until the status becomes `Ready`.
4. Click `Connect`.
From the connection drawer you can choose `Open in web` to use OpenWork Web directly in the browser, `Open in desktop`, or copy the `Connection URL` plus `Owner token` / `Client token`.
## Open it from the desktop app
The same hosted workspace also opens in the desktop app. From the connection
drawer, click `Connect` and copy the `Connection URL` plus `Owner token` /
`Client token`. In the desktop app, choose `Add workspace -> Connect custom
remote`, paste the connection URL and token, then click `Connect remote`.
## When to use OpenWork Web
Use OpenWork Web when your team needs a hosted OpenWork runtime, a stable place for long-running tasks or messaging connectors, or one workspace that several people can open from the same org — especially for teammates who should not have to install anything.
## Notes
- `DEN_OPENWORK_WEB_ENABLED=true` makes OpenWork Web available to every organization. Missing or false remains fail-closed except for an organization with an explicit complimentary grant from a platform admin in Den `/admin`; organization mode, Stripe-variable presence, and ordinary organization metadata do not act as rollout signals.
- A workspace must be `Ready` before it can be opened.
- Hosted workspace limits follow your OpenWork plan.
- If you prefer to self-host a runtime instead, run `openwork-server` and connect the desktop app to that server URL.