Rust on KnightLi Blog

RTK: A CLI Proxy That Saves Tokens for AI Coding Agents

Wed, 27 May 2026 13:52:01 +0800

rtk-ai/rtk is a command-line proxy for AI coding agents. The idea is straightforward: many agents repeatedly call ls, cat, grep, git status, git diff, test commands, and build commands while working on a project, and the raw output from those commands is often long and repetitive. RTK filters and compresses command output before it enters the LLM context, so the model sees shorter and more useful results.

Project: rtk-ai/rtk

What Problem It Solves

The real cost of AI coding tools is not only the number of model calls. It is also the useless information pushed into the context window.

For example:

ls -la may output lots of permissions, timestamps, and irrelevant files.
git diff may include a lot of repeated context.
When pytest, cargo test, or npm test fails, the important part is the failing case and stack trace, not every passing case.
docker ps, kubectl pods, and aws commands often expose many fields, while the agent only needs a few key details.

If all of that output enters the model context unchanged, it burns tokens quickly. RTK does not replace those commands. It adds a compression layer between them and the AI coding agent.

How RTK Works

RTK’s README positions it as a tool that filters and compresses command results before they reach the LLM context. It is a single Rust binary, supports many common development commands, and emphasizes low overhead.

It mainly applies four strategies:

Smart Filtering: removes comments, whitespace, boilerplate, and low-value noise.
Grouping: aggregates similar items, such as by directory, error type, or status.
Truncation: keeps the relevant context and cuts repeated or unimportant parts.
Deduplication: collapses repeated log lines into shorter counted output.

From the agent’s perspective, the commands are still familiar development commands. The difference is that the result returned to the model is shorter.

Supported Commands

RTK focuses on everyday development workflows:

Files: rtk ls, rtk read, rtk find, rtk grep
Git: rtk git status, rtk git log, rtk git diff
GitHub CLI: rtk gh pr list, rtk gh pr view, rtk gh issue list
Tests: rtk pytest, rtk go test, rtk cargo test, rtk vitest, rtk playwright test
Build and lint: rtk lint, rtk tsc, rtk next build, rtk cargo clippy
Containers and cloud: rtk docker ps, rtk docker logs, rtk kubectl pods, rtk aws sts get-caller-identity
Data and logs: rtk json, rtk deps, rtk env, rtk log

This kind of tool is most useful when an agent reads command output frequently. It does not write code for you. It helps the agent read less noise.

Installation and Integration

The README lists several installation options.

Homebrew:

`1`	`brew install rtk`

Quick install on Linux/macOS:

`1`	`curl -fsSL https://raw.githubusercontent.com/rtk-ai/rtk/refs/heads/master/install.sh \| sh`

Cargo:

`1`	`cargo install --git https://github.com/rtk-ai/rtk`

After installation, check the version and stats:

1
2

rtk --version
rtk gain

To integrate it with AI coding tools, use the init commands:

rtk init -g
rtk init -g --gemini
rtk init -g --codex
rtk init -g --agent cursor
rtk init --agent windsurf
rtk init --agent cline

Restart the corresponding AI tool after initialization. For hook-based agents, Bash commands are rewritten before execution. For example, git status becomes rtk git status, and the agent receives compressed output.

What To Watch Out For

RTK’s benefit depends on whether the agent actually reads information through shell commands.

The README specifically notes that built-in tools such as Claude Code’s Read, Grep, and Glob do not pass through the Bash hook, so they are not automatically rewritten by RTK. To make RTK participate, use shell commands such as cat, head, tail, rg, grep, and find, or call rtk read, rtk grep, and rtk find directly.

That point matters. RTK is not a globally transparent compressor for all agent I/O. It is closer to a proxy at the shell-command layer.

Windows users should also note that the README recommends placing rtk.exe in PATH and running it from Command Prompt, PowerShell, or Windows Terminal instead of double-clicking it. It also says WSL is more natural if you want the full hook experience.

Who Should Use It

RTK is useful for three groups:

Heavy AI coding users: people who ask agents to run many git, rg, test, and build commands every day.
Large-repository users: teams whose command output often reaches hundreds of lines and drowns the agent in irrelevant context.
People who care about token cost and context windows: users who want the model to focus on failures, changes, and key files.

If your project is small, or if your agent mostly reads files through IDE-native tools, RTK may feel less impactful. It shines when command-line output is both long and frequent.

My Take

RTK points in a practical direction. Many AI coding workflows focus on stronger models, larger context windows, and longer tasks, but there is still a plain development problem: agents often read far more than they need.

Compressing command output before handing it to the model can reduce token usage and lower the chance that noise steers the model in the wrong direction.

It is not a magic switch, though. To use RTK well, the agent workflow needs to lean on shell commands, and you need to confirm that the hook actually works in your current tool. For Codex, Claude Code, Gemini CLI, Cursor, and Windsurf, RTK is a useful context throttle to test: it does not change the development commands themselves, but it gives the agent cleaner results to read.

wx-cli Explained: Query Local WeChat Chat History from the Command Line

Mon, 18 May 2026 21:02:21 +0800

wx-cli is a local WeChat data command-line tool written in Rust. Its goal is to let you query your own WeChat sessions, chat history, contacts, group members, favorites, Moments, official account articles, attachments, and statistics from the terminal.

It is not a cloud-based WeChat sync service, and it is not a chatbot. It is closer to a local read-only data retrieval layer: WeChat still runs on your machine, the data still stays on your machine, and wx-cli decrypts, caches, and queries local databases on demand before returning YAML or JSON output for humans or agents.

Two points make this project worth watching. First, it turns local WeChat data access into a cross-platform CLI. Second, it explicitly considers AI Agent workflows for tools such as Claude Code, Cursor, and Codex, providing a SKILL.md file and structured output with meta fields.

What wx-cli Can Do

According to the project README, wx-cli covers a fairly complete set of features:

View recent sessions and unread sessions.
Query chat history for a contact or group.
Search keywords across the whole local database.
View newly arrived messages.
Query contacts, group members, and group nicknames.
Query favorites.
Query Moments notifications, timelines, and post bodies.
Query official account article pushes.
List and extract image attachments from chats.
Generate chat statistics.
Export chat history as Markdown or JSON.

These capabilities make it more than a “chat history search” tool. It turns local WeChat data into a searchable, analyzable, and exportable personal knowledge source.

Why It Fits AI Agents

Many CLI tools are designed only for people: their output is just a block of text. wx-cli clearly takes agent consumption into account.

The README notes that commands such as history, search, sessions, unread, new-messages, stats, and attachments include meta information. That metadata contains result status, unknown shards, the latest timestamp in matched data, the latest session timestamp, and similar fields.

This is useful for agents. AI does not only need to know “what was found”; it also needs to know whether the result is fresh, whether messages may be missing, and whether it should run init again. For example:

status can indicate whether the result is ok or possibly_stale.
unknown_shards can indicate whether there are database shards for which the daemon currently has no key.
chat_latest_timestamp tells the agent the latest message time in the matched data.
session_last_timestamp helps determine whether the local session record is clearly newer than the query result.

This kind of metadata reduces AI misjudgment and makes tools such as Claude Code, Cursor, and Codex more reliable when working with WeChat data.

Installation

The project recommends cross-platform installation via npm:

`1`	`npm install -g @jackwener/wx-cli`

It also supports curl installation on macOS / Linux:

`1`	`curl -fsSL https://raw.githubusercontent.com/jackwener/wx-cli/main/install.sh \| bash`

On Windows, run this in an administrator PowerShell:

`1`	`irm https://raw.githubusercontent.com/jackwener/wx-cli/main/install.ps1 \| iex`

If you want to build from source, you can use Rust directly:

1
2

git clone git@github.com:jackwener/wx-cli.git && cd wx-cli
cargo build --release

The build artifact is target/release/wx, or wx.exe on Windows.

Relationship with Agent Skills

wx-cli also provides a Skill for AI Agents. You can install it into Claude Code, Cursor, Codex, and other Skills-compatible environments through the skills CLI:

`1`	`npx skills add jackwener/wx-cli`

Install it globally:

`1`	`npx skills add jackwener/wx-cli -g`

After installation, the agent reads the repository’s SKILL.md and learns how to install, initialize, and call wx-cli.

That means you can ask an agent to help with local information organization tasks such as:

Find keywords discussed in a group chat during a specific period.
Summarize recent unread messages.
Export recent chat history from a specific session.
Search official account article links.
Analyze posting statistics in a group chat.

The premise is unchanged: the data must be your own WeChat data on your own machine.

Basic Usage

Before initialization, keep WeChat running. Requirements differ by platform.

On Linux:

`1`	`sudo wx init`

On Windows, use an administrator PowerShell:

wx init

macOS is more involved. The README explains that, with the default path, you first need to ad-hoc sign WeChat so the tool can scan process memory. After re-signing, you also need to clean old TCC authorization records, otherwise permissions such as screen capture, video calls, and microphone access may look enabled while actually being denied. The project documentation also warns that re-signing may cause macOS to repeatedly prompt for access to other apps’ data.

After initialization, verify the setup with:

`1`	`wx sessions`

If you can see recent sessions, the basic path is working. The daemon starts automatically on the first call.

Common Command Examples

View recent sessions:

`1`	`wx sessions`

View unread sessions:

`1`	`wx unread`

Show only human unread sessions while filtering out official accounts and folded entries:

`1`	`wx unread --filter private,group`

View recent chat history for a session:

`1`	`wx history "张三"`

Fetch more history:

`1`	`wx history "张三" -n 2000`

Query a group chat by time range:

`1`	`wx history "AI群" --since 2026-04-01 --until 2026-04-15`

Search the whole database:

`1`	`wx search "关键词"`

Search for a keyword inside a group:

`1`	`wx search "会议" --in "工作群" --since 2026-01-01`

Export chat history:

1
2

wx export "张三" --format markdown -o chat.md
wx export "AI群" --since 2026-01-01 --format json

These commands are well suited for scripts or agents, especially when combined with --json.

Moments and Official Account Articles

wx-cli does not only query chats.

Moments-related commands are split into notifications and posts:

1
2
3

wx sns-notifications
wx sns-feed
wx sns-search "关键词"

Note that Moments data only covers content that has appeared locally. The WeChat client downloads data on demand; if something has never appeared locally, the tool cannot retrieve it out of thin air.

Official account articles are queried through separate commands:

wx biz-articles
wx biz-articles --account "返朴"
wx biz-articles --since 2026-05-01 --until 2026-05-10
wx biz-articles --json | jq '.[].url'

It returns fields such as account name, title, URL, summary, cover image, and timestamp. This is useful for people who organize references, collect articles, or build local knowledge bases.

Attachment Extraction

Image attachments in WeChat chats are usually not ordinary readable image files. They are often .dat files under xwechat_files/<wxid>/msg/attach/....

wx-cli provides a two-step flow:

1
2

wx attachments "张三"
wx attachments "AI群" --kind image -n 100

After getting an attachment_id, extract it:

`1`	`wx extract <attachment_id> -o ~/Desktop/photo.jpg`

The output report includes fields such as md5, dat_path, dat_size, output, format, and decoder. The README says it supports decoding modes such as legacy XOR, V1 fixed-AES, and V2 AES + XOR, while image key extraction differs across platforms.

This capability is powerful, but it requires extra care: only process your own data, and do not use it for unauthorized data access.

Why the Daemon Architecture Matters

The performance story of wx-cli comes from its daemon.

The README describes the structure roughly as:

wx (CLI) ──Unix socket──▶ wx-daemon (background process)
                              │
                    ┌─────────┴──────────┐
               DBCache               contact cache
           (mtime-aware reuse)

After the first decryption, the daemon persists database and mtime information under ~/.wx-cli/cache/. If the database file mtime has not changed, later calls can reuse the cache without decrypting everything again.

This is important for command-line queries and agent loops. An agent may query several sessions, search multiple keywords, then run statistics and exports. If every call had to rescan and decrypt everything, the experience would be poor. The daemon cache makes it feel closer to a local query service.

A Brief Look at the Principle

The project README explains the principle directly: WeChat 4.x encrypts local databases with SQLCipher 4, and WCDB caches the derived raw key in process memory.

wx-cli uses platform-specific methods to scan WeChat process memory, match key patterns, extract the key, and then let the daemon decrypt and cache databases on demand.

The underlying mechanism differs by platform:

macOS uses the Mach VM API.
Linux uses /proc/<pid>/mem.
Windows uses VirtualQueryEx and ReadProcessMemory.

These details explain why initialization usually requires elevated permissions, and why macOS involves signing and privacy authorization.

Boundaries and Risks

Tools like this must start with boundaries.

The wx-cli README disclaimer is clear: the tool is only for learning and research, for decrypting your own WeChat data, and it requires users to comply with applicable laws and regulations. It must not be used for unauthorized data access.

In practice, it is also wise to keep these points in mind:

Use it only on your own computer and your own WeChat account.
Do not casually upload exported chat history to cloud models.
When using an agent to analyze chat history, first confirm the API provider and cross-border data risks.
After exporting Markdown / JSON, pay attention to file permissions and backup locations.
On company or shared devices, confirm compliance and authorization first.

A local tool does not mean there is no privacy risk. It reduces the default path for data to leave your machine, but if you hand the output to a cloud model, cloud drive, or third-party script, the risk comes back.

Who It Is For

wx-cli fits these scenarios:

Quickly search your own historical WeChat messages locally.
Export a session as Markdown or JSON.
Analyze posting activity in a group chat over a time range.
Let Claude Code, Cursor, Codex, and similar agents organize local WeChat material.
Collect official account article links into a local knowledge base.
Study WeChat’s local database structure and decryption flow.

It is less suitable for these scenarios:

You want cloud-based WeChat sync.
You want to bypass someone else’s device or account permissions.
You want a point-and-click GUI and do not want to touch the command line.
You do not want to deal with macOS permissions, Windows administrator rights, or Linux sudo.

Summary

The value of wx-cli is not merely “searching WeChat chat history from the command line.” More precisely, it turns local WeChat data into a local data source that can be queried, exported, and consumed by agents.

Its daemon architecture solves repeated decryption and query performance issues; the meta wrapper helps AI Agents judge whether results are fresh; and SKILL.md lets tools such as Claude Code, Cursor, and Codex understand how to install and use it.

If you often need to find information in WeChat, organize group chats, export records, or build a personal knowledge base, wx-cli is worth watching. But one bottom line should always remain clear: only process your own data, and manage exported results carefully.

References

jackwener/wx-cli GitHub repository

DeepSeek-TUI: Run a DeepSeek Coding Agent in Your Terminal

Fri, 08 May 2026 13:41:15 +0800

DeepSeek-TUI is an AI coding agent that runs in the terminal. It is built around DeepSeek V4 models and starts from the deepseek command. Inside a keyboard-driven TUI, it can read and edit files, run shell commands, search the web, manage git, connect to MCP servers, and coordinate sub-agents.

It is closer to a terminal workbench than a simple chat CLI. The goal is not only to send a question to a model, but to combine code reading, file edits, commands, diagnostics, session recovery, and workspace rollback in one local workflow.

The repository is mainly written in Rust and uses the MIT license. Its GitHub description is: “Coding agent for DeepSeek models that runs in your terminal.”

Who It Is For

DeepSeek-TUI fits developers who prefer terminal workflows and want to use DeepSeek models for real local development tasks.

It is useful when you want to:

Use DeepSeek models for code changes and project analysis.
Work without opening a full IDE.
Let an AI tool read and modify a local workspace.
Switch between Plan, Agent, and YOLO modes.
Save sessions and resume long tasks.
Roll back workspace changes.
Connect MCP, LSP diagnostics, HTTP/SSE runtime APIs, and skills.

If you only need simple Q&A, a web client or lightweight CLI is enough. DeepSeek-TUI is better when the model should become part of your local development loop.

Installation

DeepSeek-TUI ships Rust binaries. The common entry command is deepseek, and the companion TUI binary is deepseek-tui.

Using npm:

1
2
3

npm install -g deepseek-tui
deepseek --version
deepseek --model auto

The npm package is an installer and wrapper that downloads prebuilt Rust binaries. It requires Node.js >=18.

Using Cargo:

1
2

cargo install deepseek-tui-cli --locked
cargo install deepseek-tui --locked

Using Homebrew:

1
2

brew tap Hmbown/deepseek-tui
brew install deepseek-tui

You can also download prebuilt binaries from GitHub Releases. The README lists Linux x64/ARM64, macOS x64/ARM64, and Windows x64 builds.

Docker:

docker run --rm -it \
  -e DEEPSEEK_API_KEY \
  -v "$PWD:/workspace" \
  ghcr.io/hmbown/deepseek-tui:latest

In mainland China, use npm or Cargo mirrors, or download release binaries manually.

Configure the API Key

On first launch, DeepSeek-TUI asks for your DeepSeek API key and saves it to:

`1`	`~/.deepseek/config.toml`

You can also configure it explicitly:

1
2

deepseek auth set --provider deepseek
deepseek auth status

Or use an environment variable:

1
2

export DEEPSEEK_API_KEY="YOUR_KEY"
deepseek

Check the setup:

`1`	`deepseek doctor`

If the wrong key source is used, run deepseek auth status. Saved config keys take precedence over the keyring and environment variables.

Clear a saved key:

`1`	`deepseek auth clear --provider deepseek`

Auto Mode

Auto mode:

`1`	`deepseek --model auto`

Inside the TUI:

`1`	`/model auto`

Auto mode chooses both:

Model: deepseek-v4-flash or deepseek-v4-pro
Thinking: off, high, or max

Before the real request, DeepSeek-TUI makes a small routing call to analyze the latest request and recent context. Simple tasks can stay on Flash with thinking off; coding, debugging, architecture, release, security review, or ambiguous multi-step work can move to Pro or higher thinking.

auto is local to DeepSeek-TUI. The upstream API receives the concrete model and thinking setting chosen for that turn. For benchmarks, strict cost control, or fixed behavior, use an explicit model.

Modes

Mode	Use
Plan	Read-only exploration and planning
Agent	Default interactive mode with approval gates
YOLO	Auto-approve tools in a trusted workspace

Plan is for investigation. Agent is safer for everyday coding. YOLO is fast but risky and should only be used in trusted workspaces and low-risk branches.

Tooling

The README lists a broad tool set:

File reads/writes and apply patch.
Shell execution.
Git operations.
Web search and browse.
Sub-agents.
MCP servers.
LSP diagnostics.
Session save/resume.
Workspace rollback.
Durable task queue.
HTTP/SSE runtime API.
Skills system.

LSP diagnostics are especially useful because errors from rust-analyzer, pyright, typescript-language-server, gopls, clangd, and similar tools can be fed back after edits.

Workspace rollback uses side-git snapshots and provides /restore and revert_turn. It does not touch the repository’s own .git, but normal git commits are still the safest baseline.

Common Commands

deepseek
deepseek "explain this function"
deepseek --model deepseek-v4-flash "summarize"
deepseek --model auto "fix this bug"
deepseek --yolo
deepseek auth set --provider deepseek
deepseek doctor
deepseek doctor --json
deepseek models
deepseek sessions
deepseek resume --last
deepseek resume <SESSION_ID>
deepseek fork <SESSION_ID>
deepseek serve --http
deepseek serve --acp
deepseek pr <N>
deepseek mcp list
deepseek mcp validate
deepseek update

Zed and ACP

DeepSeek-TUI can run as an Agent Client Protocol server:

{
  "agent_servers": {
    "DeepSeek": {
      "type": "custom",
      "command": "deepseek",
      "args": ["serve", "--acp"],
      "env": {}
    }
  }
}

The README notes that the first ACP slice supports new sessions and prompt responses, while tool-backed editing and checkpoint replay are not exposed through ACP yet.

Configuration and Providers

User config:

`1`	`~/.deepseek/config.toml`

Workspace overlay:

`1`	`<workspace>/.deepseek/config.toml`

Some sensitive fields, such as api_key, base_url, provider, and mcp_config_path, are denied in workspace overlays.

DeepSeek-TUI supports the default deepseek provider plus NVIDIA NIM, Fireworks, OpenAI-compatible endpoints, SGLang, vLLM, Ollama, and others.

OpenAI-compatible example:

1
2

deepseek auth set --provider openai --api-key "YOUR_OPENAI_COMPATIBLE_API_KEY"
OPENAI_BASE_URL="https://openai-compatible.example/v4" deepseek --provider openai --model glm-5

Ollama example:

1
2

ollama pull deepseek-coder:1.3b
deepseek --provider ollama --model deepseek-coder:1.3b

Cost and Context

DeepSeek-TUI is designed around DeepSeek V4. The README mentions deepseek-v4-pro and deepseek-v4-flash, 1M-token context windows, token usage, cost estimates, and prefix-cache telemetry.

For light tasks, deepseek-v4-flash or auto mode may be enough. For complex refactors, long-context debugging, and architecture work, use higher thinking or Pro.

Pricing and discounts change, so check DeepSeek’s official pricing page and the current TUI cost estimates before relying on numbers.

Suggested Workflow

Start safely:

Try it in a small test repository.
Run deepseek doctor.
Use Plan mode for read-only exploration.
Use Agent mode for small edits.
Review changes with git diff and tests.
Learn /restore and session recovery.
Use YOLO only in trusted temporary branches.

Do not store API keys in project files. For company code, confirm provider, logging, web search, and compliance rules first.

Summary

DeepSeek-TUI is a full terminal AI coding agent. It brings DeepSeek V4, TUI interaction, tool calls, LSP diagnostics, session recovery, rollback, MCP, and skills into one Rust-based workflow.

It is not the lightest DeepSeek client, but its strength is moving from chat to executable local development.

References

sudo vs sudo-rs: What the Rust Version of sudo Changes

Fri, 01 May 2026 19:27:08 +0800

sudo is one of the most familiar commands for Linux users. It allows a normal user to temporarily run commands with higher privileges within an authorized scope, such as installing software, changing system configuration, or restarting services.

Recently, sudo-rs has attracted more attention because Ubuntu 25.10 starts using the Rust implementation sudo-rs by default to replace classic sudo. For ordinary users, the command on the surface is still sudo. The real change is underneath: the implementation being executed may already be the Rust version of sudo.

This raises two natural questions:

Is something wrong with classic sudo?
Will sudo-rs affect daily use and server configuration?

The short answer is: ordinary desktop users basically do not need to worry; if you maintain servers, have written complex sudoers rules, or rely on special sudo behavior, you should test carefully.

What Is sudo-rs?

sudo-rs is an implementation of sudo / su written in Rust. Its goal is not to create a completely different new command, but to reimplement the main features of classic sudo while using Rust’s memory-safety properties to reduce common security risks.

Classic sudo is mainly written in C. It has a long history and a very complete feature set. That maturity brings stability, but it also brings maintenance burden. Much of the code comes from very early Unix/Linux use cases, with many compatibility paths, extensions, and edge-case handlers added over time.

sudo-rs chooses to reimplement it for several reasons:

reduce memory-safety issues with Rust;
use a more modern code structure to lower maintenance difficulty;
remove some historical features and risky default behaviors;
attract new contributors familiar with Rust;
provide a more auditable foundation for future privilege-elevation tools.

However, sudo-rs is not a 100% compatible replacement for classic sudo. It is still under development. Some traditional features have not been implemented yet, and others may never be implemented.

What Ordinary Users Will Notice

For ordinary users, very little changes.

You still use it like this:

`1`	`sudo apt update`

Or:

`1`	`sudo systemctl restart nginx`

In Ubuntu 25.10, sudo points to sudo-rs. Users do not need to change commands to sudo-rs, and common sudo calls in scripts will not immediately fail because of a command-name change.

The most visible change is password input feedback. sudo-rs shows asterisks by default when you type the password. Classic sudo can also be configured to behave this way, but many distributions default to showing no characters.

Some error and warning messages may also use different wording. For example, password failures, permission problems, and incompatible configuration may show prompts that are not exactly the same as before. This has little impact on human users, but scripts that parse sudo’s error output should be checked.

What Administrators Should Watch

System administrators and advanced users are the ones who need to pay attention.

The classic sudo ecosystem is large, and many servers have complex sudoers configurations. These configurations may include command-argument matching, environment-variable control, logging, email notifications, PAM behavior, and host-group policies.

sudo-rs currently has some differences from classic sudo. For example, the original article notes that sudo-rs does not include classic sudo’s sendmail support. Some environments used sendmail to send notifications about sudo usage, and those setups will need another approach when migrating.

For authentication, sudo-rs uses PAM. This means behaviors such as resource limits and umask should be configured more through PAM, rather than relying entirely on the sudoers file. If you previously handled many details in sudoers, verify that those rules still work before switching.

Another important change is wildcard support in command argument positions. sudo-rs does not support wildcards in command argument positions, in order to avoid common sudoers configuration mistakes. This is good for security, but it may affect existing rules.

How Ubuntu Handles sudo and sudo-rs

Starting with Ubuntu 25.10, the system uses sudo-rs by default. Users continue typing sudo, while the Rust implementation runs underneath.

Classic sudo has not disappeared immediately. During Ubuntu’s transition, classic sudo is still kept as sudo-ws. If you truly need the traditional implementation, you can use sudo-ws, or switch the default sudo through the alternatives system.

The switching command looks like this:

`1`	`sudo update-alternatives --config sudo`

That said, ordinary users should not actively switch back to classic sudo. If you have not customized sudoers and do not rely on special behavior, following the distribution default is simpler.

If you want to test on older Ubuntu versions, sudo-rs has been available from the universe repository since Ubuntu 24.04. Other distributions may also provide packages, but command names and integration methods may differ.

Why sudo-rs Uses Rust

sudo is a high-privilege tool. If this kind of tool has a vulnerability, the consequences can be much more serious than with ordinary commands. Historically, sudo has had several privilege-escalation vulnerabilities.

Rust’s advantage is memory safety. Through ownership, borrow checking, and the type system, it reduces common problems such as dangling pointers, out-of-bounds access, and use-after-free. This does not guarantee that the program is absolutely safe, but it can reduce a class of vulnerabilities common in C/C++ projects.

For a tool like sudo, which sits in a security-sensitive position for a long time, rewriting it in a safer language has practical meaning. It is not just “Rust for Rust’s sake”; it is an attempt to reduce maintenance and audit cost.

Of course, language cannot solve every security problem. Permission-check logic, configuration parsing, PAM interaction, environment-variable handling, logging, and user experience still require careful design and long-term testing.

sudo-rs Is Not the Only Alternative

There have always been other alternatives in the sudo ecosystem.

One common example is doas. It comes from OpenBSD and is designed to be simpler, with a smaller configuration surface. Some users prefer it because it is not as complex as sudo.

There are also some Rust or systemd-related alternatives, such as RootAsRole and systemd’s run0. However, these tools do not have exactly the same goals or target scenarios.

For most Linux distributions, sudo is still the default choice. The significance of sudo-rs is that it tries to keep user habits unchanged while replacing the underlying implementation with a more modern codebase.

What to Check Before Migrating

If you are just a personal desktop user, follow the distribution default.

If you maintain servers or workstations, check the following:

Whether there are complex /etc/sudoers or /etc/sudoers.d/ rules.
Whether command-argument wildcards are used.
Whether sudo email notifications are relied on.
Whether scripts parse sudo’s error output.
Whether sudoers controls umask, resource limits, or environment variables.
Whether LDAP, PAM, SSSD, or other authentication integrations are used.
Whether automation/deployment scripts assume classic sudo behavior.

You can first verify on a test machine:

sudo -l

Then run key maintenance commands and confirm that permissions, environment variables, and logging behavior match expectations.

Should You Switch to sudo-rs Manually?

If your distribution has already switched by default, ordinary users can accept it directly. If you are using a server or production environment, do not manually replace sudo just for experimentation.

A safer process is:

install sudo-rs in a test environment;
verify existing sudoers configuration item by item;
check PAM, logging, auditing, and automation scripts;
confirm the rollback path;
migrate after the distribution provides stable integration.

This kind of tool sits on the privilege chain, so it is not enough to judge it by whether a few commands can run. The real test is boundary conditions and failure cases.

Summary

sudo-rs is a Rust implementation of classic sudo, aiming to support sudo’s core features with a more modern and safer codebase. Ubuntu 25.10 enabling it by default shows that major distributions are starting to push this direction seriously.

For ordinary users, the change is small. You still type sudo; only the underlying implementation may have become sudo-rs. At most, you may notice password asterisks or slightly different error messages.

For system administrators, compatibility is the key issue. If the system has complex sudoers rules, sendmail notifications, PAM integration, argument wildcards, or scripts that depend on sudo output, test before upgrading.

Rewriting in Rust is not a magic cure, but for a security-sensitive tool like sudo, reducing memory-safety risk and maintenance complexity is a direction worth taking seriously.

References: