DSCODE: a Mac-only coding harness where the sessions can talk to each other

A thousand stars, two forks, and an empty issue tracker

DSCODE sits at 1,020 stars with 2 forks and 0 open issues, MIT licensed, written in JavaScript, last pushed 2026-10-03. The README leans on Discussions rather than issues, and the badge row links a Discussions page directly. That ratio is the first thing worth noticing: the community surface lives in a forum, while the repository carries the file layout of something much larger than its fork count suggests. There is an AGENTS.md, a SECURITY.md, a CONTRIBUTING.md, an install.sh, an eval directory with compaction and continuation runners, a research directory, a presets directory, a plugins directory and a docker directory. All of that is scaffolding you would normally expect on a project with a far larger adoption base, and it sits next to a tracker with nothing in it.

Two descriptions of the same project do not line up word for word. The repository description calls it a DeepSeek coding agent harness with a persistent shell, Ultra subagents, auto approval, Chrome MCP and session telemetry. The manifest description calls it a reproducible macOS coding harness for the DSH-Code TUI, Chrome MCP, native computer use, skills and compaction. Chrome MCP is the only feature both names outright. Auto approval and session telemetry appear only in the repository description; native computer use, skills and compaction appear only in the manifest. Read both as partial lists rather than as a contradiction, and note that the README covers Computer Use only in passing, where it says Computer Use keeps human authorisation.

The naming is the sharper mismatch. The repository lives at qiz029/dscode and the Makefile defaults REPOSITORY to https://github.com/qiz029/dscode. The npm badge and the homepage both point at @toddzheng024/dscode. And the root manifest is called todd-dsh-tui-harness, with private set to true, so the package you install from npm is not this file. Publishing runs through hub scripts in the manifest, with separate hub and npm token entry points, which is how a private root and a public scoped package coexist. If you are reading an issue or a version mismatch, check which of the two accounts you are holding.

One shell that the TUI, the CLI and your scripts all share

The architectural claim is a single session runtime rather than one process per surface. A persistent shell keeps its working directory, its environment and its background jobs, and the TUI, the CLI and anything you script enter that same runtime instead of starting their own. File edits, search, patch application and test runs go through it, and project instructions, skills, plans, goals and hooks are wired into the same loop. DSH 0.1.5-rc.2 is the pinned harness underneath, and the README states the intent plainly: DSH dependencies, the TUI and plugins are versioned and verified together.

The command surface is small enough to learn in a minute, which is the point:

dscode sessions
dscode send <session-id> --steer
/btw why is the cache cold on the first turn?
/permission auto-review
/review-usage

The `/btw` command is the most interesting of those five. It opens a side question in its own read-only child session and answers in a panel, and the exchange never enters the main conversation. For an agent that is mid-task, that is the difference between asking what a file does and polluting the transcript that will later be reviewed or resumed. The session bridge extends the same idea across terminals: start a task in the TUI, then add requirements, read output or subscribe to progress from another terminal. The README makes one specific guarantee there, that readers never take the session write lock, which is what makes it safe to watch a long run without interfering with it.

Non-interactive use goes through `dscode exec`, which the README also pairs with a piped Git diff for review runs. The reply streams to stdout, tool activity and the session id go to stderr, and the exit code reflects the turn, with `--json` and `--resume` available. Separating the reply from the diagnostics on stderr is the detail that makes it usable in CI at all, since a script can capture the answer without parsing progress noise out of it.

Session cards, a mailbox, and an inbox you can type into

The premise the README argues for is that sessions on your machine are visible to each other, so one can hand a task over, another can review the diff, and an independent reviewer decides approvals from your instruction. Session cards are the discovery layer for that. Each session advertises its project, its workspace and the topics of its last five user requests, which the README says is enough to pick the right collaborator without opening its transcript. It also says cards describe what the user asked for rather than conclusions, which is the correct bias for an index: you want to know which session is about the parser, not which one thinks the parser is fine.

The messaging layer has named verbs and named delivery modes. The agent can find, read and message other sessions with `list_sessions`, `read_session`, `send_session` and `reply_session`, and chooses between `queue`, `steer` and `defer` for each message. A persisted mailbox, retry de-duplication and a finite budget are what keep that from turning into message loss, double processing or wake-up loops, and naming those three failure modes is a good sign about how the feature was debugged.

Memory and email sit alongside. Cross-session memory is extracted in the background and retrieved together with the workspace and source messages that produced it, can be switched off per session or globally, and has its model usage tracked separately from the session's own. The agent email feature gives every session a shared local `[ToAgent]` inbox, where a submitted message is steered into the live session as user-selected context, and with Gmail configured the same agent can send mail through the same approval flow.

Delegation is where the child cap becomes visible. Ultra uses the model's max reasoning and decides how far to investigate, delegate and verify; below Ultra the agent can still delegate but only when a task clearly warrants it. Parents pick a separate effort per child, and children that edit can work in isolated Git worktrees created from a clean HEAD. Worktree isolation for writers is the part that matters most in practice, since two children editing the same checkout is the failure mode that turns parallel agents into lost work.

A sandbox underneath, a reviewer model on top

Two approval stories appear in the README and they are worth reading together. The features table says approvals are decided by an independent reviewer from your instruction, with what it allowed and what it cost available through `/review-usage`. The guardrails row says a `workspace-write` sandbox is on by default, that Auto permission review runs on an independent model, and that it is switchable to human approval. Those hold at once if the sandbox is the outer boundary and the reviewer decides inside it, which is the reading the rest of the documentation supports. Ultra grants no extra permissions, so the highest effort setting does not widen the blast radius, and Computer Use keeps human authorisation even when everything else is automatic.

The independent review step is separate from permission review and does something different. After a code change passes its relevant checks, the agent sends the Git diff, or, outside a repository, the changes since a snapshot taken when the task began, to a separate read-only model, and then fixes concrete findings before ending the turn. `/review` runs the same reviewer by hand, scoped to the staging area, a base branch, a commit or a path. The snapshot fallback matters more than it looks: without a repository there is no diff to send, so the tool takes its own before-picture and sends the delta.

Effort is a dial rather than a mode. At Ultra the agent uses the model's `max` reasoning and decides its own depth of investigation; below Ultra delegation still exists but is expected to be justified. A parent can set a different effort per child. For anyone budgeting tokens this is the mechanism to watch, because the same task at Ultra costs more than the same task below it, and the project exposes the accounting rather than leaving you to infer it from a bill.

OpenCode Go shipped on a Tuesday and was told to log in again hours later

The three most recent releases land within about a day, and the newest pair tells a story about credentials changing faster than documentation. Version 0.7.31, published 2026-09-25 at 04:31 UTC, added OpenCode Go as a fourth provider. `/provider opencode-go` asked for a key from the OpenCode console and stored it in `~/.dscode/credentials.yaml` alongside the other provider keys, with `OPENCODE_API_KEY` in the environment taking precedence, and sent it as a bearer token to the OpenCode chat completions endpoint. Switching from DeepSeek or OpenRouter landed on the same model when Go served it, and otherwise fell back to `kimi-k3`.

Version 0.7.32, published the same day at 07:02 UTC, removed that path. The console API key 0.7.31 introduced is no longer read, and `/opencode login` now runs the OpenCode console's device login: it asks for a device code, opens the verification page, prints the code and the URL, and polls in the background because a command that has settled with one result cannot print while it waits. It handles `authorization_pending`, `slow_down` with five seconds more per answer, and transient gateway errors until the code expires at ten minutes. The login renews itself, the footer shows the subscription's use of its five-hour, weekly and monthly caps and when an exhausted cap lifts, and the consent page names the OpenCode CLI whose login client DSCODE uses. A release that retires the key path its predecessor shipped roughly two and a half hours earlier is the kind of thing you find out about from the footer rather than from a migration note.

The model catalog is probed rather than declared, and that has a cost the release body admits. Go's `/models` listing returns ids only, giving no context size, no image support and no reasoning controls, and Go passes request fields through to each model's upstream, so what a request may contain differs by model. The reasoning efforts served are the ones each model accepted on the live gateway, and the models named are DeepSeek, GLM, Kimi, MiMo, LongCat, Hy and Space Bunny, with web search through Exa. Meanwhile the repository's `.env.example` is two lines long and holds only `DEEPSEEK_API_KEY`, with a comment saying you can configure through the TUI with `/model` instead. The env file describes a credential surface that has since moved to `~/.dscode/credentials.yaml`, environment overrides and device login.

A coordinator, a kanban board, and a cap that follows your effort

`/delegate` turns the main agent into a coordinator. It plans a task on a board with priorities and dependencies, runs the parts as child agents in isolated Git worktrees, verifies each result and merges what it accepts. `/delegate-dashboard` shows that board as a kanban. Two preconditions are enforced before anything starts, that the session begins at a clean Git repository root and that it is not itself a child agent, and the transcript shows the work as a single `/delegate` line rather than dumping the coordinator protocol into your scrollback.

The child cap is the detail that changes how hard you can lean on it. A parent can run five direct children at once below Ultra and twenty at Ultra, up from three at every effort. The runtime reads the parent's effort each time it launches or wakes a child, so dropping out of Ultra brings the lower cap back immediately rather than at the next restart, and admission reservations stop concurrent launches from racing past the ceiling. One delegation level is unchanged, so a child cannot spawn its own children, and the shell policy below Ultra still asks for one child at a time outside `/delegate`, which means the runtime allows five while the prompt asks for one. Those are different numbers for different purposes: five is a hard ceiling, one is the default the agent is told to respect.

The release system is documented well enough to rehearse. The Makefile comments state that every target mirrors a step of the GitHub release workflow so the sequence can be run on your machine before a tag is pushed, and it marks itself not parallel because each phase consumes the artifacts of the one before it.

make install
make check
make release
make publish

Publishing reads three credentials, `NPM_PUBLISH_TOKEN`, `DSH_HUB_TOKEN` and, for the release asset, `GH_TOKEN`. The Makefile also records the intended split between CI and local work: the workflow stays the only path that publishes from CI, while a local `make publish` draws the npm token from the Keychain and expects the Hub token exported in your shell. `make check` runs the manifest's `check` script, which chains lint, both typechecks, coverage, integration, package and eval.

macOS, two architectures, and a Node version floor

The platform story is stated in three places and they agree. The badge says macOS 14 or later, the README says DSCODE is a terminal coding agent for macOS, and the manifest sets engines to `^22.19.0 || >=24.0.0`, which matches the Node badge reading 22.19+ or 24+. What the build system produces is the sharper boundary: the Makefile lists a source tarball plus exactly two prebuilt ones, `dscode-darwin-arm64.tar.gz` and `dscode-darwin-x64.tar.gz`. Both Apple Silicon and Intel are covered and nothing else is, so a Linux or Windows user is compiling from source rather than downloading a binary.

That constraint runs through the whole feature list. Computer Use, native window attachment, jumping to the exact terminal window of a session and the Apple integrations are macOS-shaped by construction. It also shapes what the review guarantees can promise, since a child agent in a Git worktree is an OS-level filesystem operation rather than a conceptual sandbox. Six interface languages are documented and 0.7.32 notes its new strings were translated into all six.

For a reader deciding whether to try it, the practical checklist is short: a Mac on version 14 or later, Node 22.19 or 24, at least one provider credential, and a Git repository in a clean state if you intend to use `/delegate`. The install path is the npm package with the scoped name rather than a clone, and the README's own framing of DSCODE as a pinned, reproducible harness is the reason to expect the version you install to match a known set of DSH dependencies rather than whatever a fresh resolve produces.

Editorial conclusion

DSCODE is worth a look if you already live in the terminal and want your agent sessions to be addressable objects rather than isolated windows. The pieces that are hardest to find elsewhere are the read-only side question, the session bridge that lets a second terminal add requirements without taking the write lock, and independent review that hands the Git diff to a separate read-only model. Two things to weigh first. The root manifest is a private package named todd-dsh-tui-harness while the published artifact is @toddzheng024/dscode under a different account, so trace issues against the version you actually installed. And the whole surface is macOS with darwin-arm64 and darwin-x64 tarballs as the only prebuilt targets. Start with `/btw` and `dscode sessions` before turning on `/delegate`, since the coordinator mode assumes a clean repository root and will refuse anything else.

Frequently asked questions

Official sources

1. License: MIT
2. Project website
3. qiz029/dscode on GitHub
4. README
5. Releases