56448842f0
* Let readFile callers disable the request timeout readFile resolves only when FileEnd arrives, so the default 60 s request timeout bounds the whole transfer. A large file over a slow relay fails before it finishes even though every chunk is arriving. Thread an optional timeout through requestFileExplorer; 0 disables the timer, as the workspace.create request already does, and a dead connection still rejects on disconnect. The relay e2e case reads a 1 MiB file through a real daemon and a local relay with timeout 0 and compares SHA-256 digests with the source. * Reject a binary file transfer whose byte count differs from FileBegin.size concatByteChunks allocated FileBegin.size bytes and copied the chunks in: a short transfer resolved as a zero-padded file, and a long one threw a RangeError inside the transport callback and left the request pending. Count the received bytes at FileEnd and reject the read when they differ from the announced size. * Download files over the session socket when no direct connection is active The download store only knew the HTTP token route and picked the first directTcp connection in the host profile, whatever connection the host runtime was using. A relay-only host has none, so every download ended in "Download host is unavailable." (#543). SSH, socket and pipe hosts failed the same way, and a stale directTcp entry won over a working relay (#3753). Choose the transport from the active connection: directTcp keeps the HTTP token download unchanged; anything else reads the file over the session socket with the binary frames previews already use, then hands the bytes to the browser's download manager on web and Electron or writes them to the cache directory and offers the share sheet on native. Files over 64 MiB are refused before any byte moves, using the existing fileTooLarge string, and a daemon response without content fails instead of saving an empty file. * fix(app): enforce the session download size limit during the read The token size is sampled before the file is read. Pass the download byte budget through the actual read so a changed file cannot bypass the in-memory limit. Co-authored-by: Michael Vandesompel <mv@droggol.be> Co-authored-by: YASICJUNWOO <joonoo3@naver.com> Co-authored-by: JrDw0 <JrDw0@users.noreply.github.com> * test: verify TCP downloads and own relay fixture cleanup --------- Co-authored-by: Michael Vandesompel <mv@droggol.be> Co-authored-by: paseo-bot[bot] <266920839+paseo-bot[bot]@users.noreply.github.com> Co-authored-by: YASICJUNWOO <joonoo3@naver.com> Co-authored-by: JrDw0 <JrDw0@users.noreply.github.com>
@getpaseo/client
TypeScript SDK for building integrations on top of a Paseo daemon.
npm install @getpaseo/client
import { createPaseoClient } from "@getpaseo/client";
const client = createPaseoClient({ url: "ws://127.0.0.1:6767/ws" });
await client.connect();
const agent = await client.agents.create({
config: { provider: "codex/gpt-5.5" },
cwd: "/Users/me/dev/storefront",
prompt: "Review the current diff and name the riskiest change.",
});
const result = await agent.waitForFinish();
console.log(result.lastMessage);
await client.close();
The public API is the package root. Imports under @getpaseo/client/internal/* are unsupported implementation details used by Paseo's own packages.
Read the SDK documentation for agents, workspaces, terminals, provider discovery, events, recipes, and the API reference. Runnable TypeScript patterns also live in examples/.
Runtime
The client needs a WebSocket implementation. Modern browsers and Node.js 22 provide one globally.
Use a WebSocket URL ending in /ws, such as ws://127.0.0.1:6767/ws. Pass password when the daemon requires authentication.
The client advertises its supported protocol capabilities by default. Optional capabilities
overrides extend or override that declaration; browser hosting must be supplied by the caller.
Connecting alone does not subscribe to agent timelines or catalog events. See the
event guide for subscription lifetimes and timeline replacements.
Stability
The high-level API exported from @getpaseo/client is the supported SDK surface. The SDK and daemon remain protocol-compatible across versions, but newly added capabilities can require a newer daemon.