* feat(server): let clients create internal agents The daemon's own branch-name and commit-message generators run as internal agents: never persisted, listed, flagged, announced, or seen by plugin lifecycle hooks. Nothing outside the daemon could ask for one, because the wire config schema strips `internal` and the agent.create transform re-pins it. A plugin that runs a one-turn helper per event therefore left an archived session in History every time. Add an optional `internal` flag to `create_agent_request` (inherited by `agent.create.request`), copy it onto the config in the session's create path, and skip provider session persistence for it like the generators do. The client SDK forwards the flag on both creation paths and gates it once on `server_info.features.internalAgents`. Two daemon paths assumed every agent is public and had to follow: `resolveAgentIdentifier` now accepts a live agent by exact id, since the id set it matched against came from listings that exclude internal agents and left `wait_for_finish` answering "Agent not found"; and archiving an internal agent now closes it without writing the record that `registry.applySnapshot` used to leave behind, so `autoArchive` does not accumulate hidden files on disk. Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com> * fix(server): keep internal agents whole through failure, archive, and wait Review follow-ups for internal agents: - A create that fails after the runtime is registered now closes the internal agent before rethrowing, so a hidden runtime cannot outlive the failed request. Public agents keep today's behaviour. - Archiving an internal agent cascades to attached children like any parent. cascadeArchiveChildren takes the parent record instead of reading it back from storage, where an internal agent never is. - The archived snapshot and last message of an internal agent stay readable by exact id for ten minutes, so create-then-waitForFinish returns the finished turn whether the wait lands before or after an auto-archive. Storage plays that role for public agents. - The internal-agent e2e scenarios live in the existing create_agent_request lifecycle suite rather than a new file. Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com> * fix(server): cascade to live internal children and keep a failed internal create's worktree until it closes Internal children never reach storage, so the parent archive cascade scans live agents for them as well. A failed internal create now clears the created id only after the runtime is archived, so worktree cleanup cannot delete the directory under a runtime that would not close. Stored agent payloads carry lastError, so a retained failed helper reports its error through wait_for_finish instead of the generic message. * feat(cli,mcp): expose internal agents and document --no-wait paseo run gains --internal and create_agent gains internal, both forwarded to the create request. --no-wait becomes the documented spelling for returning immediately, matching paseo send; --background and --detach stay as hidden aliases under COMPAT tags. * test: follow the --no-wait rename and stub getRetiredInternalAgent * feat: list internal agents on request and add internal workspaces Internal agents stay hidden by default, but a caller can now ask for them: `fetch_agents_request` takes `filter.includeInternal`, snapshots carry `internal: true`, and `paseo ls --internal` shows them in an INTERNAL column. The app never passes the flag. Workspaces get the same flag. `workspace.create.request` with `internal: true` persists a hidden workspace: listings, update subscriptions, sync reads, empty-project counting, open-by-path, MCP `list_workspaces`, and plugin workspace hooks all skip it unless the caller opts in with `filter.includeInternal`. Every agent created inside an internal workspace is internal and unpersisted; AgentManager applies that from the workspace id before the plugin hook so creators cannot opt out. Archive and shutdown enumerate internal agents so nothing inside an internal workspace outlives it. Surfaces: `paseo workspace create --internal`, `paseo workspace ls --internal`, `paseo run --internal --new-workspace`, MCP `create_workspace({ internal })`, SDK `workspaces.create({ internal })` and `list({ filter: { includeInternal } })`. Clients gate on `features.internalWorkspaces`. Co-Authored-By: Claude <noreply@anthropic.com> * feat(workspaces): add background visibility with inherited creation defaults * fix(cli): resolve workspace callers on the selected daemon * test(workspaces): keep caller integration coverage in server suite * test(cli): exercise workspace callers through CLI integration harness * test(mcp): remove obsolete execution flags from browser fixtures --------- Co-authored-by: marvin-ambrozio <marvin@gustavo.eng.br> Co-authored-by: Claude Fable 5.1 <noreply@anthropic.com> Co-authored-by: Mohamed Boudra <boudra.moha@gmail.com>
4.9 KiB
title, description, nav, order, category
| title | description | nav | order | category |
|---|---|---|---|---|
| Workspaces with the SDK | Open directories as Paseo workspaces, place agents in them, follow changes, and archive them. | Workspaces | 53 | TypeScript SDK |
Workspaces with the SDK
Use a workspace when an integration needs a durable place in the Paseo app for agents, terminals, browsers, and files related to one task.
Open a directory
const workspace = await client.workspaces.open("/Users/me/dev/storefront");
console.log(workspace.id);
console.log(workspace.directory);
open() creates the project when needed and reuses the active workspace for that exact directory. Use it when the directory is the identity you care about.
Create a fresh workspace
create() always creates a new workspace, even when another workspace already uses the directory:
const workspace = await client.workspaces.create({
source: {
kind: "directory",
path: "/Users/me/dev/storefront",
},
title: "Checkout issue 42",
});
Create a Paseo-owned worktree when concurrent work needs an isolated checkout:
const workspace = await client.workspaces.create({
source: {
kind: "worktree",
cwd: "/Users/me/dev/storefront",
action: "branch-off",
refName: "main",
branchName: "fix/checkout-42",
},
title: "Checkout issue 42",
});
Pass agent to create the workspace and its first agent in one call. See the
combined background workspace example.
Set visibility on the workspace options; agent.background is rejected.
You can pass projectId in either source when you already have one. Most integrations should omit it; the daemon finds or creates the project from the directory.
Pass background: true to hide a workspace from default discovery. Its agents and terminals
remain durable, with ordinary history, lifecycle hooks, archive, and exact-ID access. The app's
sidebar offers Show background without dropping replicated state.
background is creation-only. Omission defaults to false; when callerAgentId identifies an agent
creating a new workspace, omission inherits its workspace's value. Explicit false or true overrides
inheritance. Agent creation with workspaceId rejects explicit background creation intent; configure
visibility when creating the workspace. SDK/RPC implicit agent creation also accepts background
as workspace creation intent, never as an agent property.
Creation and inclusive discovery require features.backgroundWorkspaces; the client rejects an
unsupported host with an update-host message.
Start an agent in a workspace
Create through the workspace handle:
const agent = await workspace.agents.create({
config: {
provider: "claude/claude-sonnet-5",
},
prompt: "Map the checkout flow before changing anything.",
});
The handle supplies both the workspace identity and its actual directory. This avoids mismatched placement arguments.
For a one-off agent, you can skip the workspace call:
const agent = await client.agents.create({
config: {
provider: "claude/claude-sonnet-5",
},
cwd: "/Users/me/dev/storefront",
prompt: "Map the checkout flow before changing anything.",
});
The daemon still creates a project and a fresh workspace. Read agent.workspaceId when you need the generated workspace ID.
Start a terminal in a workspace
const terminal = await workspace.terminals.create({ name: "Development" });
terminal.write("echo ready");
terminal.sendKeys(["Enter"]);
const { lines } = await terminal.capture();
const { entries } = await workspace.terminals.list();
await terminal.kill();
Two workspaces may share a directory. The workspace handle supplies the ID that keeps their terminals separate. To use an ID you already have, call client.workspaces.ref(workspaceId).terminals.create().
See the terminal API reference for command arguments, working-directory overrides, input, and capture options.
List workspaces
let cursor: string | undefined;
do {
const page = await client.workspaces.list({
filter: { query: "storefront" },
page: { limit: 50, cursor },
});
for (const workspace of page.entries) {
console.log(workspace.id, workspace.name, workspace.status);
}
cursor = page.pageInfo.nextCursor ?? undefined;
} while (cursor);
Background workspaces are left out unless filter.includeBackground is true. Use
client.workspaces.list({ filter: { includeBackground: true } }) or
client.agents.list({ filter: { includeBackground: true } }). Workspace descriptors carry
background; agents derive visibility from their workspace and have no separate setting.
Refresh and archive a handle
const workspace = client.workspaces.ref(savedWorkspaceId);
const snapshot = await workspace.refresh();
if (snapshot) {
await workspace.archive();
}
Workspace archive is separate from agent archive. Archive each resource according to the lifecycle your integration owns.