computer: Offer only exec arguments that can work - #171
mattzcarey wants to merge 1 commit into
Conversation
馃 Changeset detectedLatest commit: 6f7e54d The changes in this PR will be included in the next version bump. This PR includes changesets to release 4 packages
Not sure what this means? Click here to learn what changesets are. Click here if you're a maintainer who wants to add another changeset to this PR |
|
Thanks for your interest in Cloudflare Computer. This repository does not accept unsolicited pull requests. Please use one of the accepted contribution paths instead:
If a maintainer asked you to open this pull request, they can add the |
![devin-ai-integration[bot]](https://avatars.githubusercontent.com/in/811515?s=60&v=4){kind=small}
| inputSchema, | ||
| execute: async function* ({ command, cwd, backend, env, input }, { abortSignal }) { | ||
| const selectedBackend = backend ?? options.defaultBackend; | ||
| const selectedBackend = backend ?? defaultBackend; |
There was a problem hiding this comment.
馃敶 Single-backend calls can run elsewhere
When a caller passes backend directly to execute, selectedBackend overrides the sole configured backend. On a Workspace with another registered backend, the command runs there despite the single-backend configuration.
Learn more
The tool exposes an inputSchema and an execute function. AI SDK model calls parse through the schema, which removes backend for a single-backend tool. Direct consumers can call execute without parsing; createExecutorTool demonstrates wrapping that function. The execution path still accepts the supplied backend and forwards it to WorkspaceRuntime.exec. If the Workspace registers more backends than the tool exposes, this runs on an unadvertised backend.
Example: A Workspace registers shell and container, while the tool configures only shell. Calling execute({ command: "echo hello", backend: "container" }, options) runs in container; the single-backend tool was expected to run in shell.
Recommended fix: Select onlyBackend whenever single is true, regardless of the direct call's backend field. Retain the existing default and override behavior for multiple-backend tools.
Was this helpful? React with 馃憤 or 馃憥 to provide feedback.
commit: |
f945040 to
4b6db8c
Compare
mattzcarey
changed the title
The exec tool always offered a backend argument, even with one backend configured, and always offered input, even when no backend accepted it. With one backend the model saw an enum of one value and a description written for choosing between backends. Callers also had to describe each backend by hand, so the modules a JavaScript backend installs had to be listed twice and kept in step. With one backend the tool now has no backend argument and always runs there, defaultBackend becomes optional, and the description talks about what that backend does. input appears only when some backend accepts it. A backend value sent anyway is removed by the schema. Each backend's entry adds what the backend says about itself, read through workspace.runtime.describe(id), after the caller's own description, which becomes optional for a backend that describes itself. The tool builds one input schema instead of a single-backend and a multi-backend variant, and its output truncation moves to a shared UTF-8 helper.
4b6db8c to
6f7e54d
Compare
2 participants
Stacked on #170.
The
exectool always offered abackendargument, even with one backend, and always offeredinput, even when nothing accepted it. Callers also described each backend by hand, so a JavaScript backend's modules had to be listed twice:The tool now offers only arguments that can work, and each backend's entry adds what the backend says about itself through
workspace.runtime.describe(id)(added in #170):command,cwd,envcommand,cwd,env,inputcommand,cwd,backend,env, plusinputwhen any is callable;defaultBackendrequiredWith one backend, the description covers what it does instead of how to choose. For
WorkerJavaScriptBackendthat includes its module list:A caller's
descriptionstill comes first and is required only for a backend that does not describe itself. Abackendvalue the model sends anyway is stripped by the schema, and the output still names the backend that ran. Internally, the tool builds one input schema instead of a single-backend and a multi-backend variant, and its output truncation moves to a shared UTF-8 helper.The tests read the generated JSON Schema to check which arguments the model sees, parse a call that includes
backendagainst a single-backend tool, and check the description against a realWorkerJavaScriptBackend.docs/09_tool_interface.mdcovers both configurations.