executor 1.4.0-beta.9 → 1.4.1
This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
- package/README.md +70 -340
- package/package.json +1 -1
package/README.md
CHANGED
|
@@ -1,395 +1,125 @@
|
|
|
1
1
|
# executor
|
|
2
2
|
|
|
3
|
+
[https://github.com/user-attachments/assets/11225f83-e848-42ba-99b2-a993bcc88dad](https://github.com/user-attachments/assets/11225f83-e848-42ba-99b2-a993bcc88dad)
|
|
3
4
|
|
|
4
|
-
|
|
5
|
+
The integration layer for AI agents. One catalog for every tool, shared across every agent you use.
|
|
5
6
|
|
|
6
|
-
|
|
7
|
-
`executor` is a local-first execution environment for AI agents.
|
|
8
|
-
|
|
9
|
-
It gives an agent a TypeScript runtime, a discoverable tool catalog, and a single local place to connect external systems such as MCP servers, OpenAPI APIs, and GraphQL APIs. Instead of pasting large MCP manifests into every chat or giving an agent broad shell access, you run code inside `executor` and let it call typed `tools.*` functions.
|
|
10
|
-
|
|
11
|
-
[](https://deepwiki.com/RhysSullivan/executor)
|
|
12
|
-
|
|
13
|
-
## Community
|
|
14
|
-
|
|
15
|
-
Join the Discord community: https://discord.gg/eF29HBHwM6
|
|
16
|
-
|
|
17
|
-
At runtime, `executor` behaves like one local product:
|
|
18
|
-
|
|
19
|
-
- a CLI for starting the runtime and executing code
|
|
20
|
-
- a local API server
|
|
21
|
-
- a local web UI for connecting sources, inspecting tools, and managing secrets
|
|
22
|
-
- an MCP endpoint for hosts that want to drive `executor` through MCP
|
|
23
|
-
|
|
24
|
-
The current codebase lives in `apps/` and `packages/`. Older experiments stay in `legacy/` and `legacy2/`.
|
|
25
|
-
|
|
26
|
-
## Attribution
|
|
27
|
-
|
|
28
|
-
- [Crystian](https://www.linkedin.com/in/crystian/) provided the npm package name `executor`.
|
|
29
|
-
- The `codemode` concept in this project is inspired by Cloudflare's [Code Mode announcement](https://blog.cloudflare.com/code-mode/).
|
|
30
|
-
|
|
31
|
-
## Why this exists
|
|
32
|
-
|
|
33
|
-
`executor` is built around a simple idea: agents should work against a structured tool environment instead of guessing at raw HTTP calls, carrying huge MCP definitions in context, or running arbitrary local commands with broad permissions.
|
|
34
|
-
|
|
35
|
-
In practice that means:
|
|
36
|
-
|
|
37
|
-
- sources are connected once and turned into a reusable workspace tool catalog
|
|
38
|
-
- the agent discovers tools by intent, inspects schemas, and then calls typed functions
|
|
39
|
-
- secrets and OAuth flows stay in the local runtime and web UI instead of being pasted into chat
|
|
40
|
-
- human interaction can pause an execution and resume it cleanly
|
|
41
|
-
|
|
42
|
-
## Mental model
|
|
43
|
-
|
|
44
|
-
Think of `executor` as a local control plane for agent tool use.
|
|
45
|
-
|
|
46
|
-
1. You start a local `executor` daemon.
|
|
47
|
-
2. You connect sources such as an MCP server, an OpenAPI document, or a GraphQL endpoint.
|
|
48
|
-
3. `executor` indexes those sources into a workspace tool catalog.
|
|
49
|
-
4. An agent runs TypeScript against that catalog through `executor call` or through the MCP bridge.
|
|
50
|
-
5. If a tool needs credentials or user input, execution pauses, opens a local flow, and then resumes.
|
|
51
|
-
|
|
52
|
-
## What it does today
|
|
53
|
-
|
|
54
|
-
### Connect external tool sources
|
|
55
|
-
|
|
56
|
-
`executor` currently supports these source types:
|
|
57
|
-
|
|
58
|
-
- `mcp`: remote MCP servers, including transport selection for streamable HTTP or SSE
|
|
59
|
-
- `openapi`: REST APIs described by an OpenAPI document
|
|
60
|
-
- `graphql`: GraphQL endpoints that can be introspected into callable tools
|
|
61
|
-
|
|
62
|
-
The add-source flow can:
|
|
63
|
-
|
|
64
|
-
- probe a URL and infer what kind of source it is
|
|
65
|
-
- infer likely authentication requirements
|
|
66
|
-
- prompt for credentials when discovery or connection needs them
|
|
67
|
-
- start OAuth when a source requires it
|
|
68
|
-
- persist the source and its indexed tool metadata in the local workspace
|
|
69
|
-
|
|
70
|
-
The web app also includes templates for common providers so you can start from real examples instead of filling every field by hand.
|
|
71
|
-
|
|
72
|
-
### Run agent code against tools
|
|
73
|
-
|
|
74
|
-
The main CLI workflow is `executor call`.
|
|
75
|
-
|
|
76
|
-
The runtime expects the agent to use the built-in discovery workflow:
|
|
77
|
-
|
|
78
|
-
```ts
|
|
79
|
-
const matches = await tools.discover({ query: "github issues", limit: 5 });
|
|
80
|
-
const path = matches.bestPath;
|
|
81
|
-
const detail = await tools.describe.tool({ path, includeSchemas: true });
|
|
82
|
-
|
|
83
|
-
return await tools.github.issues.list({
|
|
84
|
-
owner: "vercel",
|
|
85
|
-
repo: "next.js",
|
|
86
|
-
});
|
|
87
|
-
```
|
|
88
|
-
|
|
89
|
-
A few important rules shape the execution model:
|
|
90
|
-
|
|
91
|
-
- write TypeScript, not raw shell pipelines
|
|
92
|
-
- use `tools.*`, not direct `fetch`
|
|
93
|
-
- discover first when the exact tool path is not known
|
|
94
|
-
- inspect schemas before calling complex tools
|
|
95
|
-
|
|
96
|
-
### Handle credentials and user interaction
|
|
97
|
-
|
|
98
|
-
When a source or tool needs human input, `executor` can pause the execution and create an interaction record.
|
|
99
|
-
|
|
100
|
-
That interaction may ask you to:
|
|
101
|
-
|
|
102
|
-
- open a secure local credential page
|
|
103
|
-
- complete an OAuth flow in the browser
|
|
104
|
-
- respond to a structured elicitation from a tool host
|
|
105
|
-
- resume a paused execution from the CLI
|
|
106
|
-
|
|
107
|
-
This is the core human-in-the-loop behavior that lets `executor` keep secrets and approvals outside the agent's raw context.
|
|
108
|
-
|
|
109
|
-
### Inspect the connected tool model
|
|
110
|
-
|
|
111
|
-
The web UI is not just a setup surface. It is also where you can inspect what `executor` learned from a source.
|
|
112
|
-
|
|
113
|
-
For each source you can:
|
|
114
|
-
|
|
115
|
-
- browse its tool tree
|
|
116
|
-
- search for tools by intent
|
|
117
|
-
- inspect input and output schemas
|
|
118
|
-
- view generated manifests, definitions, and raw source documents when available
|
|
119
|
-
- edit source settings and authentication details
|
|
7
|
+
[Ask DeepWiki](https://deepwiki.com/RhysSullivan/executor)
|
|
120
8
|
|
|
121
9
|
## Quick start
|
|
122
10
|
|
|
123
|
-
If you want to use this a package distribution, install it via npm:
|
|
124
|
-
|
|
125
11
|
```bash
|
|
126
12
|
npm install -g executor
|
|
127
13
|
executor web
|
|
128
14
|
```
|
|
129
15
|
|
|
130
|
-
|
|
131
|
-
|
|
132
|
-
If you want the MCP endpoint instead, run:
|
|
133
|
-
|
|
134
|
-
```bash
|
|
135
|
-
executor mcp
|
|
136
|
-
```
|
|
16
|
+
This starts a local runtime with a web UI at `http://127.0.0.1:8788`. From there, add your first source and start using tools.
|
|
137
17
|
|
|
138
|
-
|
|
18
|
+
### Use as an MCP server
|
|
139
19
|
|
|
140
|
-
|
|
20
|
+
Point any MCP-compatible agent (Cursor, Claude Code, OpenCode, etc.) at Executor to share your tool catalog, auth, and policies across all of them.
|
|
141
21
|
|
|
142
22
|
```bash
|
|
143
|
-
executor mcp --stdio
|
|
144
|
-
```
|
|
145
|
-
|
|
146
|
-
Then you can run the CLI as `executor`.
|
|
147
|
-
|
|
148
|
-
If you are working from this repository locally, the easiest path is:
|
|
149
23
|
|
|
150
|
-
|
|
151
|
-
bun install
|
|
152
|
-
bun dev
|
|
24
|
+
executor mcp
|
|
153
25
|
```
|
|
154
26
|
|
|
155
|
-
|
|
27
|
+
Example `mcp.json` for Claude Code / Cursor:
|
|
156
28
|
|
|
157
|
-
```
|
|
158
|
-
|
|
29
|
+
```json
|
|
30
|
+
{
|
|
31
|
+
"mcpServers": {
|
|
32
|
+
"executor": {
|
|
33
|
+
"command": "executor",
|
|
34
|
+
"args": ["mcp"]
|
|
35
|
+
}
|
|
36
|
+
}
|
|
37
|
+
}
|
|
159
38
|
```
|
|
160
39
|
|
|
161
|
-
|
|
40
|
+
## Add a source
|
|
162
41
|
|
|
163
|
-
|
|
164
|
-
2. Add a source from `/sources/add`.
|
|
165
|
-
3. If needed, store credentials in `/secrets`.
|
|
166
|
-
4. Run TypeScript with `bun run executor call ...`.
|
|
42
|
+
If you can represent it with a JSON schema, it can be an integration. Executor has first-party support for OpenAPI, GraphQL, MCP, and Google Discovery — but the plugin system is open to any source type.
|
|
167
43
|
|
|
168
|
-
|
|
44
|
+
### Via the web UI
|
|
169
45
|
|
|
170
|
-
|
|
46
|
+
Open `http://127.0.0.1:8788`, go to **Add Source**, paste a URL, and Executor will detect the type, index the tools, and handle auth.
|
|
47
|
+
|
|
48
|
+
### Via the CLI
|
|
171
49
|
|
|
172
50
|
```bash
|
|
173
|
-
executor
|
|
174
|
-
|
|
175
|
-
|
|
176
|
-
|
|
177
|
-
|
|
51
|
+
executor call 'return await tools.executor.sources.add({
|
|
52
|
+
kind: "openapi",
|
|
53
|
+
name: "GitHub",
|
|
54
|
+
specUrl: "https://raw.githubusercontent.com/github/rest-api-description/main/descriptions/api.github.com/api.github.com.json",
|
|
55
|
+
baseUrl: null,
|
|
56
|
+
auth: { kind: "none" }
|
|
57
|
+
})'
|
|
178
58
|
```
|
|
179
59
|
|
|
180
|
-
|
|
60
|
+
## Use tools
|
|
181
61
|
|
|
182
|
-
|
|
183
|
-
executor up
|
|
184
|
-
executor down
|
|
185
|
-
executor status --json
|
|
186
|
-
executor doctor --json
|
|
187
|
-
```
|
|
62
|
+
Agents discover and call tools through a typed TypeScript runtime:
|
|
188
63
|
|
|
189
|
-
|
|
64
|
+
```ts
|
|
65
|
+
// discover by intent
|
|
66
|
+
const matches = await tools.discover({ query: "github issues", limit: 5 });
|
|
190
67
|
|
|
191
|
-
|
|
192
|
-
|
|
193
|
-
|
|
68
|
+
// inspect the schema
|
|
69
|
+
const detail = await tools.describe.tool({
|
|
70
|
+
path: matches.bestPath,
|
|
71
|
+
includeSchemas: true,
|
|
72
|
+
});
|
|
194
73
|
|
|
195
|
-
|
|
74
|
+
// call with type safety
|
|
75
|
+
const issues = await tools.github.issues.list({
|
|
76
|
+
owner: "vercel",
|
|
77
|
+
repo: "next.js",
|
|
78
|
+
});
|
|
79
|
+
```
|
|
80
|
+
|
|
81
|
+
Run code via the CLI:
|
|
196
82
|
|
|
197
83
|
```bash
|
|
198
|
-
executor call 'const matches = await tools.discover({ query: "repo details", limit: 1 }); return matches;'
|
|
199
84
|
executor call --file script.ts
|
|
200
|
-
|
|
201
|
-
executor call --no-open --file script.ts
|
|
85
|
+
executor call 'return await tools.discover({ query: "send email" })'
|
|
202
86
|
```
|
|
203
87
|
|
|
204
|
-
If an execution pauses, resume it
|
|
88
|
+
If an execution pauses for auth or approval, resume it:
|
|
205
89
|
|
|
206
90
|
```bash
|
|
207
91
|
executor resume --execution-id exec_123
|
|
208
92
|
```
|
|
209
93
|
|
|
210
|
-
##
|
|
211
|
-
|
|
212
|
-
There are two main ways to add a source.
|
|
213
|
-
|
|
214
|
-
### In the web UI
|
|
215
|
-
|
|
216
|
-
Use the Add Source flow to:
|
|
217
|
-
|
|
218
|
-
- paste a URL
|
|
219
|
-
- run discovery
|
|
220
|
-
- review the inferred kind, namespace, transport, and auth
|
|
221
|
-
- connect the source
|
|
222
|
-
- complete credential or OAuth setup if required
|
|
223
|
-
|
|
224
|
-
This is the easiest path for most users.
|
|
94
|
+
## CLI reference
|
|
225
95
|
|
|
226
|
-
|
|
227
|
-
|
|
228
|
-
|
|
229
|
-
|
|
230
|
-
|
|
231
|
-
|
|
232
|
-
|
|
233
|
-
|
|
234
|
-
kind: "mcp",
|
|
235
|
-
name: "Example",
|
|
236
|
-
endpoint: "https://example.com/mcp",
|
|
237
|
-
transport: "auto",
|
|
238
|
-
queryParams: null,
|
|
239
|
-
headers: null,
|
|
240
|
-
command: null,
|
|
241
|
-
args: null,
|
|
242
|
-
env: null,
|
|
243
|
-
cwd: null,
|
|
244
|
-
auth: { kind: "none" },
|
|
245
|
-
});
|
|
246
|
-
```
|
|
247
|
-
|
|
248
|
-
```ts
|
|
249
|
-
return await tools.executor.sources.add({
|
|
250
|
-
kind: "openapi",
|
|
251
|
-
name: "GitHub",
|
|
252
|
-
specUrl:
|
|
253
|
-
"https://raw.githubusercontent.com/github/rest-api-description/main/descriptions/api.github.com/api.github.com.json",
|
|
254
|
-
baseUrl: null,
|
|
255
|
-
auth: { kind: "none" },
|
|
256
|
-
});
|
|
96
|
+
```bash
|
|
97
|
+
executor web # start runtime + web UI
|
|
98
|
+
executor mcp # start MCP endpoint
|
|
99
|
+
executor call --file script.ts # execute a file
|
|
100
|
+
executor call '<code>' # execute inline code
|
|
101
|
+
executor call --stdin # execute from stdin
|
|
102
|
+
executor resume --execution-id <id> # resume paused execution
|
|
103
|
+
executor up / down / status # daemon lifecycle
|
|
257
104
|
```
|
|
258
105
|
|
|
259
|
-
|
|
260
|
-
Browser OAuth and popup-driven auth flows live on the plugin-owned HTTP and web surfaces.
|
|
261
|
-
|
|
262
|
-
## How execution works
|
|
263
|
-
|
|
264
|
-
At a high level, every execution follows the same loop:
|
|
265
|
-
|
|
266
|
-
1. `executor` resolves the current local installation and workspace.
|
|
267
|
-
2. It builds a tool catalog from built-in tools plus all connected workspace sources.
|
|
268
|
-
3. It runs your TypeScript inside the configured sandbox runtime. QuickJS is the default, and `.executor/executor.jsonc` can set `"runtime": "quickjs" | "ses" | "deno"`.
|
|
269
|
-
4. Tool calls are dispatched through `executor` rather than directly from your code.
|
|
270
|
-
5. If a tool needs interaction, the run pauses and records a pending interaction.
|
|
271
|
-
6. Once the interaction is resolved, the execution continues and eventually completes or fails.
|
|
272
|
-
|
|
273
|
-
Example:
|
|
106
|
+
## Developing locally
|
|
274
107
|
|
|
275
|
-
```
|
|
276
|
-
|
|
277
|
-
|
|
278
|
-
"sources": {}
|
|
279
|
-
}
|
|
108
|
+
```bash
|
|
109
|
+
bun install
|
|
110
|
+
bun dev
|
|
280
111
|
```
|
|
281
112
|
|
|
282
|
-
|
|
283
|
-
|
|
284
|
-
- the agent sees a coherent catalog
|
|
285
|
-
- connected sources become reusable namespace-based tools
|
|
286
|
-
- auth stays attached to sources and secret material
|
|
287
|
-
- the runtime can track execution state instead of losing it inside a one-shot prompt
|
|
288
|
-
|
|
289
|
-
## Web UI overview
|
|
290
|
-
|
|
291
|
-
The React web app is served from the same local server as the API.
|
|
292
|
-
|
|
293
|
-
Main screens:
|
|
294
|
-
|
|
295
|
-
- `/`: list connected sources in the current local workspace
|
|
296
|
-
- `/sources/add`: discover and connect new sources
|
|
297
|
-
- `/sources/:sourceId`: inspect tools, search tools, and browse source artifacts
|
|
298
|
-
- `/sources/:sourceId/edit`: edit source settings and auth
|
|
299
|
-
- `/secrets`: create, update, and delete locally stored secrets
|
|
300
|
-
|
|
301
|
-
The UI uses the same control-plane API as the CLI, so both surfaces are operating on the same local runtime state.
|
|
302
|
-
|
|
303
|
-
## Local-first runtime behavior
|
|
304
|
-
|
|
305
|
-
By default `executor` runs as a single local daemon process.
|
|
306
|
-
|
|
307
|
-
It serves:
|
|
308
|
-
|
|
309
|
-
- `/v1` for the local control-plane API
|
|
310
|
-
- `/mcp` for the `executor` MCP endpoint
|
|
311
|
-
- the web UI for normal browser routes
|
|
312
|
-
|
|
313
|
-
Default network location:
|
|
314
|
-
|
|
315
|
-
- host: `127.0.0.1`
|
|
316
|
-
- port: `8788`
|
|
113
|
+
The dev server starts at `http://127.0.0.1:8788`.
|
|
317
114
|
|
|
318
|
-
|
|
319
|
-
|
|
320
|
-
- Linux data: `~/.local/share/executor`
|
|
321
|
-
- Linux runtime state: `~/.local/state/executor/run`
|
|
322
|
-
- macOS: `~/Library/Application Support/Executor`
|
|
323
|
-
- Windows: `%LOCALAPPDATA%\Executor`
|
|
324
|
-
|
|
325
|
-
The server also maintains local PID and log files in its runtime directory.
|
|
326
|
-
|
|
327
|
-
## Persistence and data
|
|
328
|
-
|
|
329
|
-
`executor` persists the local control plane to local files.
|
|
330
|
-
|
|
331
|
-
Persisted concepts include:
|
|
332
|
-
|
|
333
|
-
- local installation identity
|
|
334
|
-
- connected sources
|
|
335
|
-
- indexed tool artifacts and related metadata
|
|
336
|
-
- credentials and secret material bindings
|
|
337
|
-
- source auth sessions
|
|
338
|
-
- execution and interaction state
|
|
339
|
-
- executions and execution interactions
|
|
340
|
-
- policies
|
|
341
|
-
|
|
342
|
-
On first start, `executor` provisions a local account, a personal organization, and a default workspace automatically.
|
|
343
|
-
|
|
344
|
-
## Security and trust model
|
|
345
|
-
|
|
346
|
-
`executor` is designed to narrow how agents interact with external systems.
|
|
347
|
-
|
|
348
|
-
Compared with direct shell or raw API usage, the model is intentionally more structured:
|
|
349
|
-
|
|
350
|
-
- tool calls are routed through a controlled runtime
|
|
351
|
-
- secrets are stored separately from prompt text
|
|
352
|
-
- OAuth and credential capture happen through local flows
|
|
353
|
-
- executions can pause for interaction instead of guessing or failing silently
|
|
354
|
-
- source auth and tool metadata live with the workspace rather than inside each prompt
|
|
355
|
-
|
|
356
|
-
This does not make the system magically risk-free, but it gives the runtime places to enforce policy, collect approvals, and keep sensitive material out of the agent's immediate context.
|
|
357
|
-
|
|
358
|
-
## Repository layout
|
|
359
|
-
|
|
360
|
-
If you are exploring the repo, these are the directories that matter most:
|
|
361
|
-
|
|
362
|
-
- `apps/executor`: packaged CLI entrypoint and daemon lifecycle commands
|
|
363
|
-
- `apps/web`: local React web UI
|
|
364
|
-
- `packages/platform/server`: local HTTP server that serves API, MCP, and UI
|
|
365
|
-
- `packages/platform/sdk`: source management, secrets, persistence, execution, and inspection
|
|
366
|
-
- `packages/platform/api`: thin HTTP adapter over the platform SDK
|
|
367
|
-
- `packages/platform/internal`: thin internal tool adapter over the platform SDK
|
|
368
|
-
- `packages/kernel/runtime-deno-subprocess`: optional Deno subprocess runtime for TypeScript execution
|
|
369
|
-
- `packages/kernel/runtime-quickjs`: default QuickJS sandbox runtime for TypeScript execution
|
|
370
|
-
- `packages/kernel/runtime-ses`: optional SES sandbox runtime for TypeScript execution
|
|
371
|
-
- `packages/hosts/mcp`: MCP bridge for `execute` and `resume`
|
|
372
|
-
- `packages/kernel/core` plus `packages/sources/*`: core tool abstractions and first-party source integrations
|
|
115
|
+
## Community
|
|
373
116
|
|
|
374
|
-
|
|
117
|
+
Join the Discord: [https://discord.gg/eF29HBHwM6](https://discord.gg/eF29HBHwM6)
|
|
375
118
|
|
|
376
|
-
|
|
377
|
-
- Merge that PR to `main`. `.github/workflows/release.yml` opens or updates a `Version Packages` release PR for version bumps and changelog updates.
|
|
378
|
-
- Merge the `Version Packages` PR. The release workflow pushes the matching git tag and dispatches `.github/workflows/publish-executor-package.yml`, which publishes to npm and creates the GitHub release.
|
|
379
|
-
- Do not edit `apps/executor/package.json` by hand for normal releases. Changesets owns the version.
|
|
380
|
-
- For a beta train, enter prerelease mode with `bun run release:beta:start`, commit `.changeset/pre.json`, and merge it. Release PRs will then use `-beta.x` versions until you exit with `bun run release:beta:stop`.
|
|
381
|
-
- `bun run --cwd apps/executor release:publish` remains the publish implementation used by CI.
|
|
382
|
-
- To build and pack the publish artifact locally without publishing, run `bun run --cwd apps/executor release:publish:dry-run`.
|
|
383
|
-
- `.github/workflows/publish-executor-package.yml` can also be run manually with a tag input if a publish needs to be retried for an already-created version tag.
|
|
384
|
-
- One-time npm setup: either configure npm trusted publishing for `RhysSullivan/executor` with the workflow file `.github/workflows/publish-executor-package.yml`, or add a GitHub Actions secret named `NPM_TOKEN` that can publish the `executor` package.
|
|
385
|
-
- Stable releases use a normal semver like `1.2.3` and publish to npm under `latest`.
|
|
386
|
-
- Beta releases use a prerelease semver like `1.3.0-beta.1` and publish to npm under `beta`.
|
|
387
|
-
- When a release should become an upgrade test fixture, capture a real workspace snapshot with `bun run fixture:release:capture -- ...` and commit it under [`packages/platform/sdk/src/runtime/__fixtures__`](./packages/platform/sdk/src/runtime/__fixtures__/README.md).
|
|
119
|
+
## Learn more
|
|
388
120
|
|
|
389
|
-
|
|
121
|
+
Visit [executor.sh](https://executor.sh) to learn more.
|
|
390
122
|
|
|
391
|
-
|
|
123
|
+
## Attribution
|
|
392
124
|
|
|
393
|
-
-
|
|
394
|
-
- `legacy/` is the original codebase
|
|
395
|
-
- `legacy2/` is the second generation
|
|
125
|
+
- Thank you to [Crystian](https://www.linkedin.com/in/crystian/) for providing the npm package name `executor`.
|