# DSCode: a local-first coding agent with DeepSeek defaults and ten providers

> An opinionated coding agent runtime that defaults to DeepSeek V4 Flash, keeps sessions as local JSONL, runs commands in an OS sandbox with the network blocked, and strips API keys out of child process environments. It admits in its own comparison document that Claude Code and Codex have broader ecosystems, and the install story has one rough edge: only the macOS builds are signed.

**thinkany-ai/dscode** — Coding agent powered by DeepSeek.

- Repository: https://github.com/thinkany-ai/dscode
- Website: https://dscode.ai
- Stars: 367 · Forks: 41
- Language: TypeScript
- License: MIT
- Published: 2026-09-17 · Updated: 2026-09-17 · Language: en
- Canonical page: https://hysenlabs.com/projects/thinkany-ai-dscode

## Ten providers behind one tool surface

The multi-provider claim is specific and worth checking against your own account, because authentication is not uniform. Each provider has an identifier and its own credential type: DeepSeek with an API key, OpenAI Codex against an eligible ChatGPT plan, OpenAI with an API key, Anthropic with either a Claude account or an API key, OpenRouter with an account or key, the Z.AI coding plan with a key, Kimi for Coding with a Kimi Code account or key, MiniMax with a key, xAI with a Grok or X account or key, and OpenCode Zen Go with a key. Two convenience aliases, kimi and grok, are accepted by the login command and the provider flag. The architectural claim is that switching provider does not change your tools or your sessions, which is the difference between a multi-provider client and a multi-provider runtime: the conversation and the worktree survive the switch, only the endpoint and model change.

## The sandbox blocks the network and the keys do not reach children

Two defaults do the heavy lifting for anyone running an agent against a real repository. Commands run inside an operating system sandbox with the network blocked by default, so a misbehaving or injected instruction cannot quietly exfiltrate anything, and API keys are removed from child-process environments, which closes the specific hole where a tool subprocess inherits a credential it has no business seeing. The sandbox is configurable rather than fixed, with an environment example showing a workspace-write mode and a hook for supplying your own reviewed container image, and the same example file exposes the permission mode and the effort level as separate knobs. The third protection is at the patch level: every successful patch creates a durable, conflict-safe checkpoint, so a bad edit is a revert rather than an archaeology exercise. None of this makes the agent trustworthy, but it changes the blast radius of a mistake from your whole machine to one reversible change.

## Credentials prefer the OS keyring, with one file at 0600 as the fallback

The credential design is the most carefully specified part of the documentation, and it is worth copying regardless of which agent you use. By default credentials go into the operating system keyring. For headless hosts or environments where no keyring service is available, there is a single owner-only fallback file, and the endpoint itself is written to a separate configuration file with restrictive permissions, alongside a credential metadata file that is explicitly non-secret and acts as an index. When you configure DeepSeek specifically, the key is masked in the prompt, and an optional base URL is offered afterwards: press Enter for the official endpoint, or supply a DeepSeek or OpenAI compatible gateway URL if you front it with your own. The resolution order for that URL is stated as the command line flag first, then the environment variable, then the saved configuration, and only then the official URL, which is the precedence you want when a debugging override has to win.

## Four parallel roles, isolated worktrees, one integrator

The parallel execution model names four roles rather than spawning anonymous workers, which is what makes the output reviewable. You can run an explorer, an implementer, a reviewer and a tester, with up to four tasks in parallel at once. Implementers work in isolated Git worktrees, so two agents editing the same repository cannot collide in the working tree, and the primary agent retains ownership of integration and final validation. That is a meaningful allocation of responsibility: the agents produce changes in parallel, and a single owner decides what lands. The same design appears in the runtime defaults, where a harness setting is configurable alongside the model, the transport, the permission mode and the sandbox mode, so the amount of agent scaffolding can be dialled from minimal upward as a repository gets more complex.

## Sessions are tree-shaped JSONL, state is SQLite, everything sits under one directory

Local-first is a layout claim as much as a philosophy, and the layout is enumerated. All global state lives under a single dot directory in the home folder: a settings file for terminal and runtime preferences, a configuration file holding storage policy and the DeepSeek endpoint, the owner-only credential fallback, the non-secret credential index, a SQLite database for thread metadata and desktop runtime state, and separate directories for global skills and global extensions. Servers, hooks and sessions have their own files, with sessions organised by year, month and day. The sessions themselves are described as tree-shaped JSONL, so a conversation is a set of append-only files rather than a row in a database, which means you can read, diff, back up or delete a session with ordinary tools. A JSONL and CI mode is also supported, so the same data can be consumed by a pipeline rather than only by the interface.

## macOS is signed and stapled, Windows and Linux are not

The desktop app ships as five platform packages, and the signing status differs by platform in a way that affects installation. There is a disk image for Apple silicon macs and a separate one for Intel macs, a Windows setup executable for x64, a Debian or Ubuntu package, and an RPM for Fedora or RHEL. The macOS builds are signed with a Developer ID certificate, notarized by Apple and stapled, which is the full treatment and means Gatekeeper stays quiet. The Windows and Linux builds are described as currently unsigned, so a user on either of those platforms will meet a warning dialog or a package manager complaint, and that is a reasonable thing to know before you hand the installer to someone else. Development and packaging details for the desktop app live in a separate document under the apps directory, and the top level of the repository also carries a native directory and an editors directory, the latter being where the VS Code entry point lives.

## The default branch is dev while the installer fetches main

There is a small inconsistency in the distribution setup that anyone installing from source should notice. The repository's default branch is dev, but the documented source install fetches a script from the main branch:

```bash
curl -fsSL https://raw.githubusercontent.com/thinkany-ai/dscode/refs/heads/main/scripts/install.sh | sh
```

The result is that a source install is pinned to main rather than to whatever the default branch currently points at, which is arguably the safer behaviour for an installer but does mean the default branch and the installed code are not guaranteed to be the same thing. The supported path is npm, and it is a single command:

```bash
npm install -g @thinkany/dscode
```

Requirements are Node.js 22.19 or newer and Git, and the runtime also uses ripgrep, with the installer preparing pnpm and installing ripgrep through Homebrew where it is available. The installed binary expects its directory on the path, and the example invocation passes the target directory explicitly with the -C flag.

## It concedes the ecosystem gap in its own comparison document

The project ships a comparison document against Claude Code and Codex, and the summary it gives is unusually self-critical, which is a good sign. The short version stated in the readme is that those products have broader and more mature ecosystems, while DSCode is smaller, DeepSeek-first, locally controlled and MIT licensed. That is an accurate summary of the trade. What you give up is the plugin and integration surface that comes with a large ecosystem; what you get is a runtime whose sessions, sandbox policy, credential handling and cost reporting you can read, plus a cost default aimed at an economical model with a large context window and a disk prefix cache that the runtime accounts for. The status command is where that accounting shows up, reporting context, cache hits, tokens, reasoning and an estimated cost, and the documentation points at the provider's current pricing page rather than quoting numbers that would go stale.

## Conclusion

DSCode is worth trying if DeepSeek pricing shapes your budget and you want a runtime you can inspect, since the sandbox defaults, the credential handling and the local session format are all documented rather than assumed. Three things to check. Only the macOS desktop builds are signed and notarized, while the Windows and Linux packages are currently unsigned, so expect a warning on those platforms. The default branch is dev while the source installer fetches from main, so a source install is not necessarily the same code as the default branch. And the parallel-agent model puts implementers in isolated Git worktrees, which changes how you integrate their output. The last push was on 2026-09-30, the CLI package version is 0.3.6, and a desktop tag shipped the same day.

## FAQ

### What is DSCode?

It is a local-first, multi-provider coding agent with DeepSeek defaults, MIT licensed and described as an opinionated coding-agent runtime. It combines provider-aware model routing with local sessions, safe patching, parallel agents, OS sandboxing and transparent usage reporting, and it ships both a terminal application and a desktop application.

### Which providers does DSCode support?

Ten, each with its own identifier and credential type: deepseek, openai-codex, openai, anthropic, openrouter, zai, kimi-coding, minimax, xai and opencode-go. Authentication ranges from an API key to an eligible ChatGPT plan, a Claude account or a Kimi Code account, and the aliases kimi and grok are accepted by the login command and the provider flag.

### How do I install DSCode?

From npm with npm install -g @thinkany/dscode, or from source with the project's install script fetched over curl. You need Node.js 22.19 or newer and Git, and the runtime also uses ripgrep, which the installer sets up through Homebrew when available. The install directory must be on your path, and you start it by passing the project directory with the -C flag.

### Does DSCode sandbox what the agent runs?

Yes. Commands run in an operating system sandbox with the network blocked by default, API keys are removed from child-process environments, the sandbox mode is configurable, and every successful patch creates a durable, conflict-safe checkpoint so a bad edit is a revert rather than a recovery exercise.

### Where does DSCode keep sessions and credentials?

All global state lives under a single dot directory in your home folder. Sessions are tree-shaped JSONL organised by year, month and day, alongside a settings file, a configuration file for storage policy and the DeepSeek endpoint, an owner-only credential fallback for headless hosts, a non-secret credential index, a SQLite database for thread metadata, and separate files for MCP servers and hooks.

## Sources

- [License: MIT](https://github.com/thinkany-ai/dscode/blob/dev/LICENSE)
- [Project website](https://dscode.ai)
- [README](https://github.com/thinkany-ai/dscode/blob/dev/README.md)
- [Releases](https://github.com/thinkany-ai/dscode/releases)
- [thinkany-ai/dscode on GitHub](https://github.com/thinkany-ai/dscode)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/thinkany-ai-dscode