mirror of
https://github.com/deepseek-ai/deepseek-harness.git
synced 2026-09-12 04:01:20 +00:00
Yichen Jiang
8470ddef1d
The package exported six functions, four of them shaped by one SDK's transport each: a dispatcher factory, a `node:http` agent factory, a proxy-URL lookup, and a policy accessor. Review asked whether the call sites could converge instead of the package growing an export per SDK. They could, and each removal took a whole shape with it: - The OTLP exporter moves to the SDK's `fetch` delegate, retiring `createNodeHttpAgent`. Its Node-version floor goes too: `proxyEnv` on an `http.Agent` needs 22.21 or 24.5, inside the engines range, so telemetry was direct on 22.19, 22.20, and 24.0-24.4. The cost is `compression`, a Node-transport option; the plugin now refuses it, `keepAlive`, and `httpAgentOptions` at load instead of ignoring them. - `web-fetch-http` builds its own address-pinning agent under an annotated `proxy-exempt:` exemption, retiring `createDispatcher`. Pinning is per-request state a process-wide dispatcher cannot hold. - E2B reads `route.proxy`, retiring `proxyUrlFor`. What remains is `installProxyFromEnvironment`, `proxyRouteFor`, `proxyEnvironmentForChild`, and `clearedProxyEnv` — one per way a caller can need the policy. Installation absorbs resolution and diagnostic reporting, which no caller needed apart. `proxyRouteFor` also closes a defect the old accessor made expressible: `web-fetch-http` read the policy to decide whether to pin, then read it again to build a transport, so an unmount between the two returned a direct, unpinned agent for a URL the first read had cleared as proxied. A route carries the answer and the transport that answer assumed. Every egress spec now installs through `installProxyFromEnvironment`, so no test asserts a policy object a real launch could not produce.
description, kind
| description | kind |
|---|---|
| The E2B remote-runtime group map: file and command work inside one remote Linux sandbox, for users and maintainers of the E2B family. | package-group |
packages/e2b
English | 中文
Summary
The e2b group moves the agent's file and command work into a remote Linux sandbox: file reads and writes, shell commands, and terminals all run in one remote world instead of on your machine. Three packages work together — one provides the shared sandbox, one runs file operations in it, and one runs commands and terminals in it. Existing shell, terminal, and language-server features keep working unchanged once the family is enabled, so no E2B-specific tooling is needed. The harness process, model calls, and session state never move — only the execution world is remote, and the sandbox is ephemeral. It is an experimental POC, and no shipped composition enables it by default.
Table of Contents
Packages
| Package | Role | ctx key |
|---|---|---|
e2b |
One shared remote Linux sandbox that file and command work runs in | ctx.e2b |
fs-e2b |
File reads, writes, edits, and listings inside the remote sandbox | ctx.fs |
subprocess-e2b |
Shell commands and interactive terminals inside the remote sandbox | ctx.subprocess |
Related documentation
- Portable execution-world decision — why the execution world can move without moving the harness, and what stays local.
- Subprocess subsystem — the subprocess seam contract and the generated Cordis surface, including
ctx.e2b. - Filesystem subsystem — the filesystem seam contract and the generated Cordis surface.
Dev Note
Working context for maintainers — click to expand
None.