| 1 | # Competitive Analysis: DeepSeek TUI vs OpenCode vs Codex CLI |
| 2 | |
| 3 | Analysis of capabilities across three AI coding agents: OpenCode (`/Volumes/VIXinSSD/opencode`), Codex CLI (`/Volumes/VIXinSSD/codex-main`), and DeepSeek TUI (`/Volumes/VIXinSSD/deepseek-tui`). |
| 4 | |
| 5 | ## Tool Matrix |
| 6 | |
| 7 | | Capability | OpenCode | Codex CLI | DeepSeek TUI | |
| 8 | |---|---|---|---| |
| 9 | | File read | ✅ Read | ✅ | ✅ file | |
| 10 | | File write | ✅ Write | ✅ | ✅ file | |
| 11 | | File edit | ✅ Edit (string replace) | ✅ apply_patch (diff format) | ✅ edit_file + apply_patch | |
| 12 | | File glob | ✅ Glob | ✅ | ✅ file_search | |
| 13 | | Code search | ✅ Grep + CodeSearch (Exa) | ✅ | ✅ grep_files + search | |
| 14 | | Shell exec | ✅ Bash | ✅ exec/shell | ✅ shell | |
| 15 | | Web fetch | ✅ WebFetch | ✅ | ✅ fetch_url | |
| 16 | | Web search | ✅ WebSearch | ✅ WebSearchRequest | ✅ web_search | |
| 17 | | Web browse | ❌ | ❌ | ✅ web_run | |
| 18 | | LSP | ✅ Lsp (experimental) | ❌ | ❌ | |
| 19 | | Task/todo tracking | ✅ TodoWrite | ✅ | ✅ todo_write | |
| 20 | | Subagent spawn | ✅ Task | ✅ Collab/SpawnCsv | ✅ agent_spawn | |
| 21 | | Skill system | ✅ Skill (multi-location discovery) | ✅ core-skills | ⚠️ Partial (.deepseek/skills/) | |
| 22 | | Plan mode | ✅ plan-enter/exit | ✅ Plan mode | ✅ Plan mode | |
| 23 | | User question | ✅ Question | ✅ request_user_input | ✅ user_input | |
| 24 | | Patch apply | ✅ apply_patch (custom format) | ✅ apply_patch (diff format) | ✅ apply_patch | |
| 25 | | Data validation | ❌ | ❌ | ✅ validate_data | |
| 26 | | Finance | ❌ | ❌ | ✅ finance | |
| 27 | | Git ops | Via Bash tool | ✅ git-utils | ✅ git module | |
| 28 | | GitHub ops | Via Bash (gh) | ✅ | ✅ github | |
| 29 | | Test running | ❌ | ✅ | ✅ test_runner | |
| 30 | | Automation | ❌ | ❌ | ✅ automation | |
| 31 | | Code review | ❌ | ✅ GuardianApproval | ✅ review | |
| 32 | | Recall/archive | ❌ | ❌ | ✅ recall_archive | |
| 33 | | Diagnostics | ❌ | ✅ | ✅ diagnostics | |
| 34 | | Revert turn | ❌ | ❌ | ✅ revert_turn | |
| 35 | | Image generation | ❌ | ✅ ImageGeneration | ❌ | |
| 36 | | Browser use | ❌ | ✅ BrowserUse | ❌ (web_run is headless) | |
| 37 | | Computer use | ❌ | ✅ ComputerUse | ❌ | |
| 38 | | Realtime voice | ❌ | ✅ RealtimeConversation | ❌ | |
| 39 | |
| 40 | --- |
| 41 | |
| 42 | ## High Priority Gaps |
| 43 | |
| 44 | These are capabilities that would most directly improve DeepSeek TUI's effectiveness as a coding agent. |
| 45 | |
| 46 | ### 1. LSP Integration |
| 47 | |
| 48 | **What it is:** A model-callable tool that queries Language Server Protocol servers for code intelligence — go-to-definition, find references, hover (type info), document symbols, workspace symbols, call hierarchy, and implementations. |
| 49 | |
| 50 | **Why it matters:** The single biggest capability gap. Every codebase exploration currently costs shell `rg` calls and sequential file reads. With LSP, the agent can jump to definitions, find all callers of a function, and inspect types in a single tool call. Estimated 30–50% reduction in exploration turns for structured codebases. |
| 51 | |
| 52 | **OpenCode implementation:** `packages/opencode/src/tool/lsp.ts` exposes nine operations with file/line/character parameters. The tool prompts are in `tool/lsp.txt`. LSP servers must be configured per file type. |
| 53 | |
| 54 | ``` |
| 55 | Supported operations: |
| 56 | - goToDefinition |
| 57 | - findReferences |
| 58 | - hover |
| 59 | - documentSymbol |
| 60 | - workspaceSymbol |
| 61 | - goToImplementation |
| 62 | - prepareCallHierarchy |
| 63 | - incomingCalls |
| 64 | - outgoingCalls |
| 65 | ``` |
| 66 | |
| 67 | **What DeepSeek TUI would need:** A new `lsp.rs` tool in `crates/tui/src/tools/`, integration with tower-lsp or lsp-server crate, and per-language server configuration. |
| 68 | |
| 69 | ### 2. Granular Permission System |
| 70 | |
| 71 | **What it is:** Allow/deny/ask rules keyed on tool name × file path pattern, with wildcard support, home-directory expansion, and cascading to pending requests. |
| 72 | |
| 73 | **Why it matters:** The current all-or-nothing approval model creates friction. Users can't express "always allow reads in `src/` but always ask for `.env` files." The ability to permanently approve a pattern reduces approval fatigue by 60–80% over a long session. |
| 74 | |
| 75 | **OpenCode implementation:** `packages/opencode/src/permission/index.ts` implements: |
| 76 | |
| 77 | - `Action`: `allow | deny | ask` |
| 78 | - `Rule`: `{ permission: string, pattern: string, action: Action }` |
| 79 | - `Ruleset`: ordered list of rules with last-match-wins semantics |
| 80 | - Pattern expansion for `~/`, `$HOME/` |
| 81 | - Wildcard matching on both permission names and path patterns |
| 82 | - Reply modes: `once` (approve this one call), `always` (approve pattern forever), `reject` (deny this one) |
| 83 | - Automatic cascading: an "always" reply auto-resolves pending requests for the same session |
| 84 | - Distinct error types: `DeniedError` (rule-based), `RejectedError` (user said no), `CorrectedError` (user said no with feedback) |
| 85 | |
| 86 | Agent definitions inherit permission rulesets that can be user-overridden: |
| 87 | ```typescript |
| 88 | build: { |
| 89 | permission: merge(defaults, { question: "allow", plan_enter: "allow" }, user), |
| 90 | } |
| 91 | plan: { |
| 92 | permission: merge(defaults, { edit: { "*": "deny" } }, user), |
| 93 | } |
| 94 | explore: { |
| 95 | permission: merge(defaults, { "*": "deny", grep: "allow", read: "allow", ... }, user), |
| 96 | } |
| 97 | ``` |
| 98 | |
| 99 | **What DeepSeek TUI would need:** A permission rule engine with the same dimension (tool name × path pattern × action), persistence to disk, and hook integration so approval decisions can cascade. |
| 100 | |
| 101 | ### 3. Lifecycle Hooks |
| 102 | |
| 103 | **What it is:** User-defined shell commands or plugin functions that fire on specific lifecycle events — before a tool executes, after it completes, when permission is requested, at session start, when the user submits a prompt, and at session stop. |
| 104 | |
| 105 | **Why it matters:** Hooks are the escape hatch that lets users enforce invariants without polluting the system prompt. "Always run `cargo fmt` after writing a `.rs` file." "Warn me before any `rm -rf`." "Log every shell command to a file." They are composable, auditable, and don't consume context window tokens. |
| 106 | |
| 107 | **Codex CLI implementation:** `codex-rs/hooks/` defines six event types with typed request/response payloads: |
| 108 | |
| 109 | | Event | When it fires | Payload | |
| 110 | |---|---|---| |
| 111 | | `PreToolUse` | Before tool execution | tool name, input params, sandbox state | |
| 112 | | `PostToolUse` | After tool execution | tool name, input, success/failure, duration, output preview | |
| 113 | | `PermissionRequest` | When model requests permission | permission type, justification | |
| 114 | | `SessionStart` | New session begins | session ID, cwd, source (new/resume) | |
| 115 | | `UserPromptSubmit` | User sends a message | prompt text | |
| 116 | | `Stop` | Session ending | reason | |
| 117 | |
| 118 | Each hook handler supports: |
| 119 | - `matcher`: optional regex to filter which tool calls trigger the hook |
| 120 | - `command`: shell command to run |
| 121 | - `timeout_sec`: maximum runtime |
| 122 | - `status_message`: shown to the user while the hook runs |
| 123 | - `source_path` + `source`: tracks where the hook was defined (project hooks.json, user config, plugin) |
| 124 | - Hooks can return `Success`, `FailedContinue`, or `FailedAbort` (blocks the operation) |
| 125 | |
| 126 | **What DeepSeek TUI would need:** Extend `crates/hooks/` to support the full event surface, add matcher-based filtering, and provide a `hooks.json` discovery mechanism similar to Codex CLI's. |
| 127 | |
| 128 | ### 4. Persistent Memories |
| 129 | |
| 130 | **What it is:** Automatic extraction of user preferences, project conventions, and past decisions from conversations, stored as retrievable memories that are injected into new sessions. |
| 131 | |
| 132 | **Why it matters:** Across a long debugging session, the agent rediscovers the same facts: "this project uses Rust edition 2024," "tests run with `cargo test --workspace`," "the user prefers 4-space indentation." A memory system compounds value — each session builds on prior knowledge rather than starting from zero. |
| 133 | |
| 134 | **Codex CLI implementation:** The `MemoryTool` feature (experimental, behind `/experimental` menu) enables: |
| 135 | - Memory generation: the model creates structured memories from conversation content |
| 136 | - Memory retrieval: relevant memories are injected into new conversation context |
| 137 | - The `Chronicle` feature adds passive screen-context memories via a sidecar process |
| 138 | - Memories are stored in SQLite and surfaced in the TUI via `/memories` command |
| 139 | |
| 140 | **What DeepSeek TUI would need:** A memory extraction prompt, a vector or keyword-based retrieval system, and storage in the existing session/state infrastructure. |
| 141 | |
| 142 | ### 5. Skill Auto-Discovery |
| 143 | |
| 144 | **What it is:** Automatic scanning of multiple locations for `SKILL.md` files that provide domain-specific instructions, scripts, and references. Skills are injected into the conversation on demand via a `skill` tool. |
| 145 | |
| 146 | **Why it matters:** Skills are how the community packages expertise. A "Rust refactoring" skill, a "Docker deployment" skill, a "GitHub Actions" skill — each provides specialized instructions without bloating the main system prompt. OpenCode's multi-location discovery means skills can be project-local, user-global, or pulled from URLs. |
| 147 | |
| 148 | **OpenCode implementation:** `packages/opencode/src/skill/index.ts` scans: |
| 149 | |
| 150 | 1. `~/.claude/skills/**/SKILL.md` (Claude Code compatibility) |
| 151 | 2. `~/.agents/skills/**/SKILL.md` (Agents SDK compatibility) |
| 152 | 3. Parent directories from cwd to workspace root for `.claude/skills/` and `.agents/skills/` |
| 153 | 4. Project config directories for `{skill,skills}/**/SKILL.md` |
| 154 | 5. User-configured paths (with `~/` expansion) |
| 155 | 6. User-configured URLs (pulled via discovery module) |
| 156 | |
| 157 | Skills are parsed for YAML frontmatter (`name`, `description`) and Markdown content. Duplicate names warn but don't error. Skills respect agent permissions — an agent can only load skills its permission ruleset allows. |
| 158 | |
| 159 | **What DeepSeek TUI would need:** Extend the existing `~/.deepseek/skills/` discovery to parent-directory walking, Claude Code compatibility paths, and URL-based skill sources. Add YAML frontmatter parsing. |
| 160 | |
| 161 | --- |
| 162 | |
| 163 | ## Medium Priority Gaps |
| 164 | |
| 165 | These would meaningfully improve the agent experience but are less urgent. |
| 166 | |
| 167 | ### 6. Agent Profiles with Permission Inheritance |
| 168 | |
| 169 | **What it is:** Named agent types (build, plan, general, explore) that inherit different tool permission sets. Users can define custom agents with specific models, temperatures, system prompts, and permission rules. |
| 170 | |
| 171 | **OpenCode implementation:** `packages/opencode/src/agent/agent.ts`: |
| 172 | |
| 173 | - `build`: full-access with ask on sensitive paths |
| 174 | - `plan`: all edit tools denied, plan-exit allowed, plan file writes in `.opencode/plans/` allowed |
| 175 | - `general`: subagent-only, todo-write denied |
| 176 | - `explore`: read-only, grep/glob/read/bash/webfetch/websearch allowed |
| 177 | - Plus hidden agents for internal tasks (compaction, title generation, summarization) |
| 178 | |
| 179 | Each agent carries its own `model`, `temperature`, `topP`, `prompt`, and `permission` ruleset. A `generate` function creates new agent configs dynamically from user descriptions. |
| 180 | |
| 181 | **What DeepSeek TUI would need:** Extend the mode system (Plan/Agent/YOLO) to support named agent profiles with per-profile tool filtering and model configuration. |
| 182 | |
| 183 | ### 7. Shell Sandboxing |
| 184 | |
| 185 | **What it is:** OS-level sandbox enforcement for shell commands — network restrictions, filesystem read-only mounts, allowed/disallowed paths. |
| 186 | |
| 187 | **Codex CLI implementation:** `codex-rs/sandboxing/`: |
| 188 | |
| 189 | - macOS: Seatbelt (`sandboxing/src/seatbelt.rs`) with `.sbpl` policy files |
| 190 | - Linux: bubblewrap (default) or Landlock (legacy fallback) |
| 191 | - Windows: restricted token |
| 192 | - Configurable sandbox policies per command |
| 193 | - Integration tests can detect they're running under sandbox and early-exit |
| 194 | |
| 195 | **What DeepSeek TUI would need:** Extend `crates/execpolicy/` to support platform-specific sandbox enforcement. Start with macOS Seatbelt (most DeepSeek TUI users are on macOS). |
| 196 | |
| 197 | ### 8. Tool Search / Deferred MCP Tool Exposure |
| 198 | |
| 199 | **What it is:** Instead of dumping all MCP tools into the system prompt (bloating context), expose a `tool_search` function that the model calls to discover relevant tools by name or description. |
| 200 | |
| 201 | **Codex CLI implementation:** `ToolSearch` feature (stable, default-enabled). `ToolSearchAlwaysDeferMcpTools` goes further — never exposes MCP tools directly, always requires search. This is critical when MCP servers expose hundreds of tools. |
| 202 | |
| 203 | **What DeepSeek TUI would need:** `tool_search_tool_regex` and `tool_search_tool_bm25` already exist as deferred tool discovery mechanisms. Extend them to gate MCP tool exposure behind on-demand search. |
| 204 | |
| 205 | ### 9. ExecPolicy / Command Approval Rules |
| 206 | |
| 207 | **What it is:** A policy engine that evaluates shell commands against user-defined rules — prefix allowlists, network restrictions, pattern matching — and auto-approves, denies, or escalates. |
| 208 | |
| 209 | **Codex CLI implementation:** `codex-rs/execpolicy/src/`: |
| 210 | |
| 211 | - `Policy`: ordered list of `Rule` entries |
| 212 | - `Rule`: prefix patterns (e.g., allow `cargo build*`, deny `rm *`) |
| 213 | - `NetworkRule`: protocol-level network restrictions |
| 214 | - `MatchOptions`: controls rule evaluation behavior |
| 215 | - `Evaluation`: result of policy evaluation against a command |
| 216 | |
| 217 | Rules can be amended at runtime via `blocking_append_allow_prefix_rule`. |
| 218 | |
| 219 | **What DeepSeek TUI would need:** Extend `crates/execpolicy/` to support prefix rules, network rules, and runtime policy amendments. |
| 220 | |
| 221 | ### 10. Dynamic Agent Generation |
| 222 | |
| 223 | **What it is:** On-the-fly generation of new agent configurations from natural language descriptions. |
| 224 | |
| 225 | **OpenCode implementation:** The `generate` function in `agent.ts` takes a description like "code reviewer that only reads files and reports issues" and returns an `{ identifier, whenToUse, systemPrompt }` object using a structured LLM call. Generated agents respect existing agent name collisions. |
| 226 | |
| 227 | **What DeepSeek TUI would need:** A model-callable tool or slash command that generates agent configs from descriptions and registers them for the session. |
| 228 | |
| 229 | ### 11. Streaming Patch Events |
| 230 | |
| 231 | **What it is:** Structured progress events streamed while the model is generating `apply_patch` input, giving the user real-time feedback on what files will change. |
| 232 | |
| 233 | **Codex CLI implementation:** `ApplyPatchStreamingEvents` feature (under development) streams file-level progress as the model produces patch hunks. The `StreamingPatchParser` in `apply-patch/src/streaming_parser.rs` handles incremental parsing. |
| 234 | |
| 235 | **What DeepSeek TUI would need:** Extend `apply_patch.rs` to emit progress events during streaming model output. |
| 236 | |
| 237 | --- |
| 238 | |
| 239 | ## Lower Priority Gaps |
| 240 | |
| 241 | Specialized features that are valuable but less critical for core coding workflow. |
| 242 | |
| 243 | | Capability | Where | Notes | |
| 244 | |---|---|---| |
| 245 | | Image Generation | Codex CLI `ImageGeneration` | Niche for coding; useful for documentation diagrams | |
| 246 | | Browser Use | Codex CLI `BrowserUse` | Interactive browser automation (click, type, screenshot). DeepSeek TUI has `web_run` for headless | |
| 247 | | Computer Use | Codex CLI `ComputerUse` | Full desktop automation. Desktop-app-gated | |
| 248 | | Realtime Voice | Codex CLI `RealtimeConversation` | Voice conversation mode. Experimental | |
| 249 | | Unified PTY Exec | Codex CLI `UnifiedExec` | Single PTY-backed shell with state snapshotting across turns | |
| 250 | | Artifacts | Codex CLI `Artifact` | Native artifact rendering tools | |
| 251 | | Goals | Codex CLI `Goals` | Persistent thread goals that survive compaction and session restarts | |
| 252 | | Git Commit Attribution | Codex CLI `CodexGitCommit` | Model instructions for proper commit attribution | |
| 253 | | CSV Agent Spawning | Codex CLI `SpawnCsv` | CSV-backed parallel agent job distribution | |
| 254 | | Shell Snapshotting | Codex CLI `ShellSnapshot` | Save/restore shell state across turns | |
| 255 | | Prevent Idle Sleep | Codex CLI `PreventIdleSleep` | Keep machine awake during long-running agent tasks | |
| 256 | |
| 257 | --- |
| 258 | |
| 259 | ## Architectural Patterns |
| 260 | |
| 261 | ### OpenCode |
| 262 | |
| 263 | **Client/Server Architecture:** The TUI is one client; the server can be driven remotely from a mobile app, desktop app, or web console. This decouples the agent runtime from the UI layer. |
| 264 | |
| 265 | **Plugin System:** `packages/opencode/src/plugin/` supports hot-loadable JS/TS plugins that add tools, models, auth providers, and chat middleware. Plugins receive a typed context with tool execution, auth, and filesystem access. |
| 266 | |
| 267 | **Multi-Provider:** Not coupled to any single AI provider. Models are configured with provider IDs and resolved through a provider registry. OAuth support for OpenAI Codex (ChatGPT subscription integration) in `plugin/codex.ts`. |
| 268 | |
| 269 | **Config Layering:** Config is loaded from multiple sources (global, project, env vars) and merged with well-defined precedence. |
| 270 | |
| 271 | ### Codex CLI |
| 272 | |
| 273 | **App-Server Protocol:** `codex-rs/app-server-protocol/` defines a versioned RPC protocol (v2) between the TUI frontend and the agent backend. All new API development goes through v2 with strict naming conventions (`*Params`/`*Response`/`*Notification`, `resource/method` RPC naming). |
| 274 | |
| 275 | **Feature Flag System:** `codex-rs/features/` centralizes 60+ feature flags with lifecycle stages (UnderDevelopment, Experimental, Stable, Deprecated, Removed). Features have metadata (menu name, description, announcement text) and can carry custom config structs. |
| 276 | |
| 277 | **Bazel + Cargo Dual Build:** Codex CLI uses both Cargo (for development) and Bazel (for CI/release). The `find_resource!` macro and `cargo_bin()` helper abstract over runfile differences. |
| 278 | |
| 279 | **Snapshot Testing:** `codex-rs/tui/` extensively uses `insta` for UI snapshot tests. Any UI change requires corresponding snapshot coverage. |
| 280 | |
| 281 | **Core Modularity:** Explicit resistance to adding code to `codex-core`. New functionality goes into purpose-built crates (`codex-apply-patch`, `codex-memories`, `codex-sandboxing`) rather than growing the core crate. |
| 282 | |
| 283 | ### DeepSeek TUI |
| 284 | |
| 285 | **RLM (Recursive Language Model):** Unique in this space. A sandboxed Python REPL where a sub-LLM can call helpers (`llm_query`, `llm_query_batched`, `rlm_query`) for batch processing, chunking, and recursive critique. Neither competitor has an equivalent. |
| 286 | |
| 287 | **Durable Tasks:** Restart-aware persistent task objects with evidence tracking (gate runs, PR attempts, timeline). Designed for long-running autonomous work that survives restarts. |
| 288 | |
| 289 | **Automations:** Scheduled recurring tasks with cron-style RRULE recurrence. Unique among the three. |
| 290 | |
| 291 | --- |
| 292 | |
| 293 | ## What DeepSeek TUI Already Excels At |
| 294 | |
| 295 | - **RLM** — batch/bulk LLM processing in a Python sandbox; no equivalent in either competitor |
| 296 | - **Finance** — live stock/crypto quotes; unique in this space |
| 297 | - **Automations** — scheduled recurring tasks with cron rules |
| 298 | - **Durable tasks** — restart-aware with evidence tracking and gate verification |
| 299 | - **Turn revert** — undo workspace changes per turn via side-git snapshots |
| 300 | - **Data validation** — JSON/TOML validation tool |
| 301 | - **Web run** — headless browser interaction (Codex CLI has Browser Use but it's desktop-app-gated) |
| 302 | - **Parallel tool execution** — explicitly modeled as infrastructure |
| 303 | - **Git/GitHub operations** — comprehensive git module with blame, log, diff, status plus full GitHub API via gh |
| 304 | - **Project map** — high-level project structure generation |
| 305 | |
| 306 | --- |
| 307 | |
| 308 | ## Recommended Implementation Order |
| 309 | |
| 310 | 1. **LSP tool** — single biggest capability gap. Estimated 30–50% reduction in codebase exploration turns. |
| 311 | 2. **Path-pattern permissions** — reduces approval fatigue by 60–80% over long sessions. |
| 312 | 3. **Persistent memory** — compounds value across sessions; foundational for long-running projects. |
| 313 | 4. **Pre/Post-tool-use hooks** — escape hatch for user-defined guardrails without system prompt bloat. |
| 314 | 5. **Skill auto-discovery** — enables community skill ecosystem and Claude Code compatibility. |
| 315 | 6. **Agent profiles** — named agent types with model/permission inheritance. |
| 316 | 7. **Tool search for MCP** — keeps context window manageable when connecting to MCP servers with many tools. |
| 317 | 8. **Shell sandboxing** — security improvement, starting with macOS Seatbelt. |
| 318 |