How the Reasonix Desktop Application Integrates with the CLI Engine: Shared Kernel Architecture

The Reasonix desktop application embeds the same Go kernel used by the CLI via a Wails-based UI shell, importing identical internal providers and delegating all heavy lifting to shared services while using the CLI binary as a side-car for remote SSH windows.

The Reasonix project (esengine/DeepSeek-Reasonix) delivers a unified AI coding experience across terminal and graphical interfaces. Rather than maintaining separate codebases, the Reasonix desktop application integrates with the CLI engine by importing the same internal packages and runtime kernel, ensuring consistent behavior whether you run reasonix in a terminal or click through the native desktop UI.

Shared Kernel and Provider Architecture

Both the CLI (cmd/reasonix/main.go) and the desktop binary (desktop/main.go) execute boot.Build to resolve providers, tools, and agents from a registry built at compile-time. The desktop source uses blank imports to pull the exact same provider packages as the CLI:

// desktop/main.go
_ "reasonix/internal/provider/anthropic"   // ← same providers as CLI
_ "reasonix/internal/provider/openai"
_ "reasonix/internal/provider/responses"
_ "reasonix/internal/tool/builtin"

These imports mirror those found in cmd/reasonix/main.go. Because both binaries link the same internal packages, configuration handling (~/.reasonix/config.toml) and credential management remain identical across front-ends.

Wails as the UI Shell

The desktop entry point creates a Wails application via wails.Run, providing a native window and WebView (WebKit on macOS/Linux, WebView2 on Windows). This runtime serves as a thin shell—all session management, agent orchestration, MCP handling, and billing logic delegates to the internal/control and internal/agent services that the CLI also consumes.

In desktop/main.go (lines 96–105), the application initializes the Wails host while embedding the kernel as a Go library, ensuring the desktop does not reimplement core functionality.

CLI Side-Car Pattern for Remote Windows

When spawning remote SSH windows, the desktop UI does not instantiate another full desktop stack. Instead, it launches the CLI binary as a helper process. The function desktopCLIBinaryPath in desktop/remote_app.go discovers the appropriate CLI executable:

// desktop/remote_app.go
func desktopCLIBinaryPath() string {
    packagedName, commandName := desktopCLIBinaryNames(runtime.GOOS)
    // …search $PATH and the executable’s directory…
    // returns the first regular, executable file found
}

This helper binary provides identical model-selection, credential handling, and tooling resolution as the main CLI, guaranteeing remote windows behave exactly like standard reasonix terminal sessions.

Unified State and Plugin Management

Both interfaces share plugin hosts (sharedPluginHost) created per-workspace root to avoid duplicate CodeGraph subprocesses. The desktop tracks these shared hosts in desktop/app.go:

// desktop/app.go (excerpt)
sharedHosts   map[string]*sharedPluginHost // ← shared between desktop tabs and CLI runtimes

All persistent data lives under ~/.reasonix (or $REASONIX_HOME). The desktop reads and writes the same session files (desktop-tabs.json, heartbeat-tasks.json) as the CLI, enabling seamless transitions between terminal and graphical interfaces.

Summary

• Common kernel: Both binaries import identical internal packages via boot.Build, ensuring provider and tool parity.
• Wails embedding: The desktop uses a lightweight Wails shell that delegates to the same control and agent services as the CLI.
• CLI side-car: Remote SSH windows spawn the CLI binary via desktopCLIBinaryPath, reusing the command-line engine for remote sessions.
• Shared state: Configuration, credentials, and plugin hosts reside in ~/.reasonix, unifying state across both interfaces.

Frequently Asked Questions

Does the Reasonix desktop application duplicate CLI functionality?

No. The desktop application imports the same internal kernel packages as the CLI and delegates all heavy lifting—such as agent execution, provider resolution, and tool management—to the shared services found in internal/control and internal/agent.

How does the desktop app locate the CLI binary for remote windows?

The desktopCLIBinaryPath function in desktop/remote_app.go searches the system $PATH and the executable's directory to locate either reasonix-cli.exe (Windows) or reasonix (Unix), ensuring the correct side-car binary is used for remote SSH sessions.

Can I use the same configuration for both CLI and desktop?

Yes. Both interfaces read from ~/.reasonix/config.toml and share credential stores. A session started in the CLI appears as a tab in the desktop UI, and vice versa, because both write to the same desktop-tabs.json and session state files.

What technology powers the Reasonix desktop interface?

The desktop uses Wails, a Go framework that embeds a WebView (WebKit or WebView2) inside a native window. This provides a modern web-based UI while keeping the heavy computational logic in Go, unlike Electron which bundles a separate Chromium instance.

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