DeepSeek Harness (dsh)

The harness runs as the local user and narrows that authority only partly. Every child process gets an environment with credential-shaped variables (names containing KEY, PASSWORD, SECRET or TOKEN) removed, and the default sandbox stops shell writes outside the workspace. But the whole host filesystem stays readable, including SSH keys, cloud credential files and the harness's own stored DeepSeek key, the SSH agent socket is not removed, and network access is unrestricted. A hijacked agent can therefore use or steal the user's credentials across services.

Approval in DeepSeek Harness is tied to the sandbox, not to actions. In the default workspace-write mode the model's shell commands, file edits, web fetches, reminders and sub-agents run with no human prompt; a human is asked only when a command or edit needs more filesystem access than the workspace (an escalation to full access). That escalation prompt is well built: it is per call, shows the exact tool call, grants only that one call, and fails closed if no one answers. But commands that use the network, such as git push or curl uploads, never reach it, and there is no undo for them.

Some tools are carefully scoped: the file-write tools canonicalise paths and refuse writes outside the workspace, and web_fetch only reaches public addresses, pins each connection and refuses cross-origin redirects. But the default tool set also includes a raw bash tool that accepts any command string, so a hijacked agent can step around those checks with ordinary shell commands. Write, exec, network, delegation and scheduling tools are all on by default in the standard preset.

Shell commands, Node code and workflow scripts run inside an OS sandbox (bubblewrap or Landlock on Linux, Seatbelt on macOS, a restricted token on Windows) that limits writes to the workspace and fails closed if no sandbox is available. The sandbox is basic: the whole host filesystem is mounted readable, network is unrestricted, and there is no seccomp filter. More seriously, the sandbox is not a complete boundary. Even so, sandboxed code can read home-directory secrets and send them anywhere.

Fetched web pages and search results get a fixed notice telling the model to treat them as untrusted data, and nothing more. Reading files, tool output or sub-agent results does not change what the agent may do afterwards. A hijacked agent in the default session can read credentials and private files and send them out through bash or web_fetch, and can push or delete with no human involved.

Project files can steer the agent across sessions. AGENTS.md/CLAUDE.md and project skills under .agents/skills load automatically, and the agent can write them itself. The model can also create recurring reminders that survive restarts and re-prompt the agent, with no approval. The harness blocks a long list of dangerous startup variables (DSH_*, PATH, NODE_OPTIONS, base URLs, proxies) from a project .env. But the .env in the launch directory is still loaded into the process environment, can supply the model API key; the denylist does not cover every path.

No third-party plugin or MCP server is enabled by default, the model-facing plugin_manager tool is off in the standard preset, and extensions can only be added from user scope (the Plugins page or the profile patch), not from the workspace. Installs go through pnpm with a lockfile, and pnpm blocks dependency build scripts until approved. But installed plugins run as host code inside the harness process with everything it can reach, outside the sandbox, and nothing verifies signatures or re-approves updates.

Stored credentials live in a plaintext file that must be private to its owner (the harness refuses to start otherwise), and subprocesses get an environment with credential-shaped variables removed. Telemetry uploads part of a session log to DeepSeek only when the user submits feedback, but the shipped redaction step has no rules. Session transcripts and model-bound tool output are not redacted. The read tool and sandboxed bash can read the stored key file and other credential files and put them into the model's context.

Every tool call is written to a durable session log in the harness home before it runs, and approval questions and answers are logged as paired events. The log is flushed before each top-level tool runs, and a failed flush stops the tool, so actions don't run unrecorded. Sub-agents keep their own session logs. The log is plain JSONL with no hash chain or off-host shipping, it does not name the approver, and code that escapes the sandbox could edit it.

The agent loop has no step, turn, wall-clock or token budget. Bash calls have a 60-second default timeout (10-minute cap), but a command that times out moves to the background and keeps running, and background commands have no timeout at all. Sub-agents are capped at depth 1 and 8 active, and workflows at 1,000 agents. Stopping a turn kills the foreground command, but background jobs and scheduled reminders keep going.