How to Set Up a DeepSeek-Reasonix Development Environment: CLI and Desktop Build Guide

Install Go 1.25+, Node 24+, and Wails CLI, then use make build for the CLI or make wails-build for the desktop app—both share the same kernel in internal/control so you can develop components independently.

DeepSeek-Reasonix is a Go-based autonomous coding agent developed by esengine that ships as a CLI/TUI, desktop application, and VS Code extension. Whether you're customizing the built-in tools, adding a new model provider, or hacking on the React/Vite desktop UI, this guide walks you through a complete local development setup using the exact source file paths and build commands from the repository.

Prerequisites for DeepSeek-Reasonix Development

Before building, ensure your system meets these requirements:

• Go 1.25+ — Required for both CLI and desktop modules
• Node 24+ and pnpm 10 — Desktop front-end dependencies only
• Wails CLI — Must match the pinned version in .wails-version (desktop only)
• Platform-specific webview libraries — See desktop/frontend/README.md for your OS

On macOS, you can install everything via Homebrew:

brew install go node pnpm wails

Cloning the Repository

Start by cloning the main repository and entering the project directory:

git clone https://github.com/esengine/DeepSeek-Reasonix.git
cd DeepSeek-Reasonix

The repository uses a monorepo structure where the kernel (internal/*), CLI (cmd/reasonix), and desktop (desktop/) modules coexist. The kernel is deliberately stateless except for a configurable home directory, enabling parallel development without interference.

Building and Running the CLI

The CLI entry point at cmd/reasonix/main.go wires subcommands and imports internal/control.Controller to power the agent loop.

Step 1: Compile the Binary

make build

This produces bin/reasonix (or bin/reasonix.exe on Windows).

Step 2: Run the Setup Wizard

Isolate your development environment by setting REASONIX_HOME to a temporary directory:

REASONIX_HOME=/tmp/reasonix-dev ./bin/reasonix setup

The wizard writes configuration to reasonix.toml and prompts you to select a provider and model. The default OpenAI-compatible provider implementation lives in internal/provider/openai/*.

Step 3: Start an Interactive Session

REASONIX_HOME=/tmp/reasonix-dev ./bin/reasonix

The controller in internal/control/controller.go orchestrates the agent loop, tools, and providers—this same kernel is reused by the desktop app.

Building and Running the Desktop Application

The desktop module (desktop/) is a separate Go module that embeds a React/Vite web-view through Wails. It reuses internal/control.Controller but adds native windowing, event handling, and platform-specific web-view libraries.

Step 1: Install Wails and Front-End Dependencies

make wails-install    # Installs exact Wails version from .wails-version

cd desktop
pnpm install          # Installs React/Vite dependencies

Step 2: Build the Desktop Binary

make wails-build      # Or run `wails build` directly

Output appears in dist/ as Reasonix.app (macOS), Reasonix.exe (Windows), or equivalent.

Step 3: Launch with Isolated Home Directory

REASONIX_HOME=/tmp/reasonix-desktop ./dist/Reasonix

The desktop/main.go file bootstraps Wails and embeds the kernel, demonstrating how the transport-agnostic controller adapts to different interfaces.

Understanding the Kernel Architecture

Several key patterns in internal/control/controller.go make independent development possible:

Component	Location	Purpose
Controller	internal/control/controller.go	Orchestrates agent loop, tool registry, and provider dispatch
Built-in tools	internal/tool/builtin/*	Self-register via tool.RegisterBuiltin during init()
Providers	internal/provider/*	OpenAI-compatible backends configured via TOML
CLI entry	cmd/reasonix/main.go	Subcommand routing and kernel instantiation
Desktop entry	desktop/main.go	Wails bootstrap with shared kernel

Because the kernel reads REASONIX_HOME at runtime, you can run stable releases and development builds side-by-side without configuration collisions.

Running Tests

Validate your changes before submitting:

make test                # Full Go test suite (kernel, tools, providers)

make desktop-test        # Desktop-specific integration tests

make desktop-test-short  # Faster subset for rapid iteration

Customizing Built-In Tools and Providers

To extend Reasonix:

1. Add a tool: Implement internal/tool/builtin/yourtool.go and call tool.RegisterBuiltin in init(). Existing tools like bash and read_file provide templates.
2. Add a provider: Create internal/provider/yourprovider/ implementing the provider interface, then reference it in reasonix.toml.
3. Modify the UI: Edit React components in desktop/frontend/—the Wails bridge in desktop/main.go surface kernel methods to JavaScript.

See CONTRIBUTING.md for the full development checklist and environment isolation guidance.

Summary

• DeepSeek-Reasonix development requires Go 1.25+ for all targets, plus Node/pnpm/Wails for desktop
• The kernel in internal/control powers both CLI (cmd/reasonix) and desktop (desktop/main.go) through a transport-agnostic controller
• Use REASONIX_HOME to isolate development, staging, and production environments
• Run make build for CLI, make wails-build for desktop, and make test for validation
• Built-in tools self-register at init() time; providers are TOML-configurable

Frequently Asked Questions

What is the minimum Go version for DeepSeek-Reasonix development?

Go 1.25 or later is required. The codebase uses language features and standard library packages introduced in recent releases, and both the CLI and desktop modules depend on this version.

Can I develop the CLI without installing Node or Wails?

Yes. The CLI depends only on Go. Node 24+, pnpm 10, and Wails CLI are required exclusively for building the desktop application's React/Vite front-end.

How do I run multiple Reasonix instances without conflicts?

Set distinct REASONIX_HOME directories for each instance. For example, use /tmp/reasonix-dev for development builds and ~/.reasonix for stable releases. The kernel loads configuration and state exclusively from this path.

Where do built-in tools register themselves?

Each tool in internal/tool/builtin/* calls tool.RegisterBuiltin during package initialization (init()). The controller discovers available tools automatically at startup without manual registry updates.

{
  "mcpServers": {
    "instagit": {
      "command": "npx",
      "args": ["-y", "instagit@latest"]
    }
  }
}