executor 1.4.0 → 1.4.2

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.
Files changed (2) hide show
  1. package/README.md +70 -340
  2. 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
- https://github.com/user-attachments/assets/11225f83-e848-42ba-99b2-a993bcc88dad
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
- [![Ask DeepWiki](https://deepwiki.com/badge.svg)](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
- That starts a foreground local session, prints the local web URL, and keeps it alive until you press `Ctrl+C`.
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:4788`. From there, add your first source and start using tools.
137
17
 
138
- That prints the local MCP URL and keeps the session alive until you press `Ctrl+C`.
18
+ ### Use as an MCP server
139
19
 
140
- If you want a local stdio MCP server for agent configs such as Codex or OpenCode, run:
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
- ```bash
151
- bun install
152
- bun dev
24
+ executor mcp
153
25
  ```
154
26
 
155
- That starts the local runtime. The default base URL is:
27
+ Example `mcp.json` for Claude Code / Cursor:
156
28
 
157
- ```text
158
- http://127.0.0.1:8788
29
+ ```json
30
+ {
31
+ "mcpServers": {
32
+ "executor": {
33
+ "command": "executor",
34
+ "args": ["mcp"]
35
+ }
36
+ }
37
+ }
159
38
  ```
160
39
 
161
- From there:
40
+ ## Add a source
162
41
 
163
- 1. Open the web UI in your browser.
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
- If you are using a packaged distribution, the command name is simply `executor` instead of `bun run executor`.
44
+ ### Via the web UI
169
45
 
170
- ## Core CLI commands
46
+ Open `http://127.0.0.1:4788`, 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 web
174
- executor mcp
175
- executor mcp --stdio
176
- executor call --file script.ts
177
- executor resume --execution-id exec_123
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
- Compatibility commands for the detached daemon are still available:
60
+ ## Use tools
181
61
 
182
- ```bash
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
- `executor call` accepts code in three ways:
64
+ ```ts
65
+ // discover by intent
66
+ const matches = await tools.discover({ query: "github issues", limit: 5 });
190
67
 
191
- - inline as a positional argument
192
- - from `--file`
193
- - from standard input with `--stdin`
68
+ // inspect the schema
69
+ const detail = await tools.describe.tool({
70
+ path: matches.bestPath,
71
+ includeSchemas: true,
72
+ });
194
73
 
195
- Examples:
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
- cat script.ts | executor call --stdin
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 with:
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
- ## Adding a source
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
- ### From inside an execution
227
-
228
- The runtime also exposes `tools.executor.sources.add(...)`, which lets an agent add a source from code.
229
-
230
- Examples:
231
-
232
- ```ts
233
- return await tools.executor.sources.add({
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
- `executor.sources.add(...)` accepts the final plugin-specific source config.
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
- ```jsonc
276
- {
277
- "runtime": "ses",
278
- "sources": {}
279
- }
108
+ ```bash
109
+ bun install
110
+ bun dev
280
111
  ```
281
112
 
282
- This gives you a stable surface for agent automation:
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:4788`.
317
114
 
318
- Default data locations are OS-aware:
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
- ## Releasing
117
+ Join the Discord: [https://discord.gg/eF29HBHwM6](https://discord.gg/eF29HBHwM6)
375
118
 
376
- - Add a changeset in any PR that should release: `bun run changeset`.
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
- ## Project status
121
+ Visit [executor.sh](https://executor.sh) to learn more.
390
122
 
391
- This repository is explicitly on its third major architecture iteration.
123
+ ## Attribution
392
124
 
393
- - `apps/` and `packages/` are the active implementation
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`.
package/package.json CHANGED
@@ -1,6 +1,6 @@
1
1
  {
2
2
  "name": "executor",
3
- "version": "1.4.0",
3
+ "version": "1.4.2",
4
4
  "description": "Local AI executor with a CLI, local API server, and web UI.",
5
5
  "keywords": [
6
6
  "executor",