[FEATURE] Rewrite Claude Code Client in the V Programming Language

Preflight Checklist

• [x] I have searched existing requests and this feature hasn't been requested yet
• [x] This is a single feature request (not multiple features)

Problem Statement

Claude Code's TypeScript/Node.js (Bun) implementation has well-documented, systemic resource management problems that are architectural in nature - not merely bugs to be patched. The issue tracker tells a consistent story of a runtime environment fundamentally unsuited to a long-running, resource-sensitive CLI tool.

The Evidence

Memory leaks and bloat are endemic and worsening:

• Issue #17037 - A single Claude Code process consumes 500 MB of RAM at baseline. The reporter notes this should be 50 MB or less for a CLI tool. (Closed as duplicate, confirming it's a known class of problem.)
• Issue #17650 (closed) - Claude Code consumes ~3 GB of RAM within less than a minute of starting, even with MCP servers disabled and minimal usage. The process is "a single Node.js instance with ~20 worker threads."
• Issue #21923 (open, filed Jan 30, 2026) - Sessions spike to ~12 GB memory when reviewing changes. Multiple processes show 11.46-11.58 GB each in Activity Monitor. The process becomes unresponsive and must be force-killed.
• Issue #19056 (closed, duplicate) - User reports memory consumption figures of 50 GB growing to over 108 GB as reported by macOS on an M4 Pro with 24 GB physical RAM, requiring force-close. "This happened 3 times today."
• Issue #11377 (closed) - After 14 hours: ~23 GB virtual memory, 143.8% CPU, process stuck and system unresponsive. Page fault counter overflowed at 2,147,483,647 (max int32). System experienced severe swap thrashing (~334M swap-ins, ~357M swap-outs per vm_stat).
• Issue #15963 (open) - Excessive RAM consumption on fresh install - the bloat begins at installation time.

Performance degradation over time is structural:

• Issue #10881 (open, since Nov 2025) - "After long sessions, Claude Code becomes slower and slower to the point that it takes several minutes between requests." This is the textbook signature of GC pressure + unbounded accumulation in a garbage-collected runtime.
• Issue #18319 (open) - "When running for long periods of time, the runtime becomes slow and memory seems to balloon." Lock acquisition failures confirm contention in the runtime.
• Issue #19452 (open) - General performance degradation after recent updates, tagged perf:memory.

CPU thrashing when idle:

• Issue #18280 (closed, duplicate) - Comprehensive strace/perf/bpftrace investigation reveals Claude Code's idle process consuming 50-80% CPU within 2-5 minutes of startup. The root cause: a tight mmap/munmap loop allocating and immediately freeing 4KB pages at ~110 cycles per second while doing nothing. A 16ms timer loop (consistent with 60fps frame timing) fires continuously even when idle, likely driving the allocation thrashing. Thread sampling showed the main thread at 33.0% CPU and seven HeapHelper (GC) threads at ~2.4-2.5% each, adding 16.8% GC overhead. A single idle session accumulated 42 GB of I/O reads over 2.5 hours. The investigator concluded the timer-driven allocation loop was the primary CPU consumer.

Startup time regressions:

• Issue #18479 (closed, duplicate) - Startup takes ~5 minutes in v2.1.9 (vs. seconds in v2.1.7). The changelog itself acknowledges "multiple optimizations to improve startup performance" and "native binary installs now launch quicker" - admissions that startup is a persistent problem area.
• Issue #5771 (open, since Aug 2025) - 100% CPU and memory consumption when running build commands or cleaning .git directories, hanging the computer entirely.

Native binary complications:

• Issue #18273 (closed, duplicate) - Windows security update causes native binary to crash with access violation (0xC0000005) - the investigator concluded the update "likely introduced stricter memory protection policies or code signing requirements that the native claude.exe binary couldn't satisfy."
• Issue #14165 (open) - Native binary ignores HTTP_PROXY because Bun's fetch() and Node's axios use different HTTP stacks. The native binary is an awkward hybrid.
• Issue #5209 (closed) - Native binary installation hangs on Linux servers without npm.
• Issue #13574 (closed) - Installation script reports "✅ Installation complete!" even when the binary installation fails.

Prior Rewrite Requests

The community has already formally requested a rewrite:

• Issue #17037 - "[FEATURE] Claude Code in Rust or Golang" - Closed as duplicate, meaning Anthropic acknowledges this is a recurring request.
• PR #11583 - A community member (0xinf0) submitted a complete Rust rewrite (13,125 lines, 10 crates, 188 tests, 100% pass rate). The author closed this PR and resubmitted as PR #11666 ("Initial implementation: Claude Code in Rust"), which was subsequently closed without merge by an Anthropic engineer (ant-kurt). PR #11583's benchmarks:

| Metric | Current (TypeScript/Bun) | Rust Rewrite |
|--------|--------------------------|--------------|
| Binary/distribution size | ~174-224 MB (native binary) or ~68 MB (npm) | 2.1 MB optimized binary |
| External deps | Node.js/Bun runtime | None (zero runtime deps) |
| Tests | N/A | 188 (100% pass rate) |
| Unsafe code | N/A | Zero |

The author closed #11583 and resubmitted as #11666, which Anthropic subsequently closed without merge. The likely reasons are discussed below.

Proposed Solution

Rewrite in V

The V programming language (vlang.io) addresses every single problem documented above while offering specific advantages over both the current TypeScript implementation AND the previously proposed Rust rewrite.

Why V and Not Rust or Go

The Rust PRs were closed without merge. The likely reasons are: Rust's steep learning curve makes it expensive to staff; Rust's compilation times are slow (on par with C++), making the rapid iteration cycle Anthropic needs for a consumer product painful; and Rust's borrow checker, while brilliant for systems programming, is overkill for a CLI tool that primarily does HTTP streaming, file I/O, and terminal rendering.

Go would be the obvious safe choice, but Go's garbage collector introduces the same class of problems (memory bloat under pressure, GC pauses, unpredictable latency) that plague the current Node.js implementation - just less severely. Go binaries are also large (typically 10-20 MB+).

V occupies the sweet spot:

| Property | TypeScript/Bun | Go | Rust | V |
|----------|---------------|-----|------|-------|
| Compilation speed | N/A (interpreted/JIT) | Fast | Slow (C++ tier) | ~500k loc/s (tcc), ~110k loc/s (clang) |
| Runtime dependencies | Node.js/Bun | Go runtime + GC | None | None |
| Memory management | GC (V8/JSCore) | GC | Ownership/borrow | 4 options: GC, autofree, arena, manual |
| Learning curve | Low | Low | Steep | Low (Go-like syntax, minimal design) |
| Distribution size | ~174-224 MB (native) / ~68 MB (npm) | 10-20 MB | 2.1 MB (PR #11583) | Estimated 2-3 MB |
| C interop | FFI/NAPI | cgo (slow) | Direct FFI | Direct (compiles to C) |
| Startup time | Seconds to minutes (varies; 5-min regression in v2.1.9) | ~50 ms | Near-instant (native binary) | Near-instant (native binary) |
| Idle CPU | 50-80% (mmap thrash + GC) | Low (but GC cycles) | Near-zero | Near-zero |

V's Specific Advantages for Claude Code

1. The Memory Problem Disappears

V compiles to human-readable C via its primary backend. This means:

• No garbage collector thrashing (the #1 root cause of Claude Code's memory/CPU issues)
• With -autofree, the compiler statically inserts free() calls at compile time - covering ~90-100% of allocations without developer effort (note: autofree is still experimental per vlang.io, planned for V 1.0)
• Default mode uses lightweight Boehm GC, with manual management (-gc none) or arena allocation (-prealloc) also available
• Value types by default (stack allocation) means most objects never touch the heap
• The mmap/munmap thrashing loop documented in Issue #18280 (110 allocation cycles/second while idle) becomes structurally impossible

2. Compilation Speed Enables Anthropic's Iteration Cadence

Claude Code ships updates multiple times per week. Looking at the changelog, some weeks see 3-4 releases. Rust's compilation times would be a serious friction point for this cadence. V compiles itself in under 1 second. A project the size of Claude Code (~15-20k lines estimated) would compile in well under 5 seconds on the tcc backend, or under 30 seconds with optimized clang output. This is development-cycle-compatible in a way Rust is not.

3. Tiny, Self-Contained Binaries

V produces static binaries as small as ~16 KB (hello world) to ~328 KB (full HTTP server) when compiled with -compress -gc none -cflags -static flags. Even with default GC enabled and no compression, binaries remain small. A complex CLI tool with HTTP streaming, JSON parsing, terminal rendering, and file operations would likely come in at 2-3 MB - comparable to the Rust rewrite's 2.1 MB, and a fraction of the current ~174-224 MB native binary distribution (or ~68 MB npm package). No more "native binary installation hangs" or "install script reports success when installation fails" - it's a single file you copy.

4. C Interop Is Free

V compiles to C. This means any C library is directly callable without FFI overhead, binding generators, or wrapper layers. If Claude Code needs to interface with system APIs, terminal libraries (ncurses, etc.), or crypto libraries, the integration is trivial. This also means V code can incrementally replace C code, enabling a phased migration strategy.

5. The Syntax Is Approachable

V reads like a cleaned-up Go with no semicolons, immutability by default, and mandatory error handling. A developer who knows Go, Python, or even the existing TypeScript codebase can be productive in V within days. This directly addresses the staffing concern that likely led to the Rust PR being rejected.

Sample of what Claude Code's streaming client might look like in V:

module api

import net.http
import json
import time

struct StreamEvent {
    event_type string
    data       string
}

fn (mut c Client) stream_messages(prompt string) !chan StreamEvent {
    ch := chan StreamEvent{cap: 64}

    spawn fn [mut c, prompt, ch] () {
        mut req := http.new_request(.post, c.base_url + '/v1/messages',
            json.encode(MessageRequest{
                model:      c.model
                max_tokens: c.max_tokens
                messages:   [Message{role: 'user', content: prompt}]
                stream:     true
            })
        ) or {
            ch.close()
            return
        }
        req.add_header(.content_type, 'application/json')
        req.add_header(.custom_header('x-api-key'), c.api_key)
        req.add_header(.custom_header('anthropic-version'), '2023-06-01')

        resp := req.do() or {
            ch.close()
            return
        }

        for line in resp.body.split_into_lines() {
            if line.starts_with('data: ') {
                ch <- StreamEvent{
                    data: line[6..]
                }
            }
        }
        ch.close()
    }()

    return ch
}

Clean, readable, no ceremony. The error handling (! and or blocks) is mandatory but unobtrusive.

6. Hot Code Reloading for Development

V supports hot code reloading natively - change code, see results instantly without restarting. For a tool like Claude Code where the edit-test cycle involves starting a session, loading context, and running through conversation flows, this alone could dramatically accelerate development.

Addressing Potential Objections

"V is not mature enough"

V has been in active development since 2019, compiles its own compiler, and appears in the TIOBE index (positions 51-100 as of January 2026). Its standard library includes HTTP client/server with SSE support, JSON, crypto, OS interfaces, regex, and terminal handling - every primitive Claude Code needs. The V compiler is written in V and bootstraps from C, demonstrating self-hosting capability. Note: V's autofree feature is still experimental (not production-ready), as acknowledged on vlang.io, and V has not yet reached version 1.0.

"The ecosystem is too small"

Claude Code's dependency surface is actually narrow: HTTP client with SSE streaming, JSON serialization, terminal UI rendering, file system operations, process spawning, and OAuth flows. All of these are available in V's standard library or via trivial C interop. The current implementation doesn't use exotic npm packages - it mostly fights against Node.js's runtime behavior.

"Nobody on the team knows V"

V was explicitly designed for simplicity, with "only one way of doing things" according to vlang.io. Its syntax is deliberately minimal. Given that the Claude Code team clearly has systems-level expertise (they've already attempted Bun native binaries, investigated GC behavior, and implemented frame-tick optimizations), learning V would be a minor investment compared to the ongoing cost of fighting Node.js's runtime characteristics.

"We can just fix the Node.js issues"

The issue tracker proves otherwise. Memory and performance issues have been reported continuously since at least August 2025 (Issue #5771). The perf:memory label is one of the most active tags. Version after version, the changelog lists memory and performance fixes, yet new regressions appear with equal frequency. The mmap/munmap thrashing loop (Issue #18280) demonstrates that even "optimizations" introduce new resource problems. This is not a bug problem - it's an architecture problem. The runtime is the wrong tool for the job.

---

Implementation Strategy

AI-assisted development has fundamentally changed the economics of rewrites. The Rust PR (#11583/#11666) produced 13,125 lines of working Rust with 216 passing tests in under 12 hours using AI assistance. V's dramatically simpler syntax and smaller cognitive surface area make it an even better target for AI-assisted code generation than Rust.

For context: One V developer has already reverse-engineered Claude Code's architecture and produced a working prototype in approximately one day using Claude Code itself as the development tool. The functional surface area of Claude Code - HTTP streaming client, terminal UI, file/process operations, JSON-RPC for MCP, OAuth flows - maps almost 1:1 onto V's standard library.

Realistic timeline with AI-assisted development:

| Phase | Scope | Estimate |
|-------|-------|----------|
| Core CLI + terminal UI + config | Entry point, arg parsing, REPL loop, terminal rendering | Day 1 |
| HTTP streaming client | Anthropic API client, SSE parsing, auth/OAuth | Day 1-2 |
| Tool execution framework | Bash exec, file ops, search, directory traversal | Day 2-3 |
| MCP protocol | JSON-RPC client/server, tool registration, spawn concurrency | Day 3-4 |
| Session management + polish | Persistence, conversation history, plugin loading, edge cases | Day 4-5 |
| Testing + hardening | Cross-platform validation, stress testing, regression suite | Day 5-7 |

Total estimated timeline: 1-2 weeks for a single experienced V developer with AI-assisted tooling. A small team could compress this to days. The bottleneck is not writing code - it's testing edge cases and platform-specific behavior.

This is not speculation. The Rust rewrite already proved a single developer can produce a feature-complete implementation in hours. V's simpler syntax, faster compilation (instant feedback loop), and direct stdlib coverage of every required primitive make it an even faster target.

Alternative Solutions

_No response_

Priority

High - Significant impact on productivity

Feature Category

Interactive mode (TUI)

Use Case Example

_No response_

Additional Context

The community has demonstrated both the demand (Issue #17037, closed as duplicate of a prior request) and the feasibility (PRs #11583/#11666, a working Rust rewrite produced in under 12 hours with AI assistance). V offers everything Rust offers for this use case - native performance, tiny binaries, zero dependencies, memory safety - while removing the barriers that likely prevented the Rust rewrite from being adopted: slow compilation, steep learning curve, and high maintenance burden.

The question is not whether the TypeScript implementation should be replaced. The issue tracker has already answered that. The question is: replaced with what? _V is the right answer_.