Skip to content

[Feature]: Native (Rust) binary / Rust core for Auggie CLI (lower memory + faster startup + no Node 22+ dependency) #62

@rishitank

Description

@rishitank

What would you like to be added?

A native, prebuilt auggie distribution implemented in Rust (or a hybrid architecture where performance-critical components are in Rust), so Auggie can be installed and run without requiring a system-level Node.js 22+ runtime.

Concretely, I’d love one of these:

  • Option A (ideal): A full Rust-native auggie CLI/TUI binary that preserves the current UX and flags.
  • Option B (incremental): Keep the Node/TS UI layer, but move heavy local work into a Rust “core” (invoked via local RPC/stdio or a small native module), and ship a native binary for the core.

Why is this needed?

  1. Installation friction / portability

    • Today, Auggie is installed via npm and requires Node.js 22+. This is a hurdle in minimal containers, CI agents, enterprise environments, and servers where upgrading Node is non-trivial.
    • A single native binary would make “runs anywhere” a reality (especially for automation workflows).
  2. Performance + reliability (startup + memory)

    • Auggie is commonly used in non-interactive “automation” mode (e.g. --print) where cold-start time matters a lot.
    • There are also reports of high memory usage / Node heap OOM behavior in real server environments. A native implementation (or Rust core) could reduce baseline overhead and make resource usage more predictable.
  3. Auggie’s workload benefits from systems-level efficiency

    • Auggie automatically indexes workspaces and traverses lots of files (respecting .gitignore / .augmentignore). That type of IO-heavy, streaming, concurrency-friendly workload is a strong fit for Rust and can be done with very low overhead.

Possible solution or alternatives

  • Option A: Full Rust CLI/TUI

    • Provide prebuilt binaries for macOS/Linux/Windows (WSL ok) with the same commands/flags.
    • Publish a small benchmark note (startup time, RSS, indexing speed on a representative repo).
  • Option B: Hybrid approach (recommended if rewrite scope is big)

    • Keep Node/TS for the interactive UX, but move these components to Rust:
      1. Workspace traversal + ignore matching + streaming reads (indexing pipeline)
      2. Diff/patch application + file ops planning
      3. Process management, cancellation, cleanup for reliability
    • Node CLI delegates to Rust core over stdio/local RPC.
  • Alternative mitigations (if Rust isn’t on the roadmap)

    • Ship officially supported Docker images for CI.
    • Offer a “self-contained” binary distribution built from the existing code (even if larger), to remove the external Node requirement.
    • Provide documented memory controls (e.g., supported NODE_OPTIONS usage) and profiling guidance.

Additional context

No response

Metadata

Metadata

Assignees

No one assigned

    Labels

    enhancementNew feature or request

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions