DEV Community: Xynorash

Your AI coding agent can read your SSH keys. I built a Neovim plugin that won't start it unprotected

Xynorash — Fri, 30 Oct 2026 11:13:37 +0000

If your editor can launch a coding agent, that agent runs with your privileges: your ~/.ssh, your cloud credentials, your git history. One day I caught myself asking what exactly stops it from touching all that. The answer was "nothing", which wakes you up faster than coffee. So I wrote a plugin that makes my editor refuse to start the agent unprotected.

It is one of nine standalone plugins I extracted from xynovim, my Neovim config for Rust. All are MIT, all need Neovim 0.12+, and you can install any of them without the rest of the config. Splitting them out taught me more than writing them did (my ego has not fully recovered).

xyno-sandbox.nvim: an agent that refuses to start unprotected

The plugin runs a command-line agent inside bubblewrap: a read-only filesystem except the project and a scratch directory, credential folders such as ~/.ssh and ~/.aws replaced with empty ones, secret-looking environment variables removed, and git directories locked read-only.

The design rule is that it fails closed. If no sandbox can be created, the agent does not start, and Windows and macOS are refused rather than silently run without one.

It is also honest about its limits. It is a denylist on a read-only view, the network stays open, and the agent can still read its own token file. It is a seatbelt, not a security boundary against a determined attacker, and the README says so. Yes, I put that in my own README. Marketing departments hate this one trick.

xyno-guard.nvim: auto-save with a conscience

Auto-save plugins are happy to write any buffer. In Rust that goes wrong in three ways: a save lands in ~/.cargo/registry or the standard library sources, a save overwrites a file that git checkout or a formatter just changed on disk, or Neovim stops on a blocking W12 prompt.

The guard records each file's mtime when it is read or written, and refuses to save if disk has moved on. Dependency and standard-library buffers are set to readonly, so auto-save never touches them (:set modifiable still lets you edit one on purpose). It also re-checks at write time, because some auto-save plugins write up to a second after their condition check. It works with any auto-save plugin that takes a condition function. This one was born from pure annoyance, the most renewable energy source in software.

xyno-history.nvim: Local History on plain git

JetBrains has Local History, and I missed it. (Yes, I shamelessly borrowed the idea. JetBrains, if you are reading this, I still use your IDEs every day. Please be gentle.) Every throttled save becomes a commit on a private ref, refs/lochist/<branch>, with the full worktree as its tree. Your index, stash and branches are never touched.

Two details mattered most. Each Neovim process builds its snapshot with its own private index file and updates the ref with a compare-and-swap, so several instances saving at once do not overwrite each other. And because the snapshots are ordinary git objects, you can recover without the plugin: git log refs/lochist/main and git restore --source=refs/lochist/main. Saves are throttled to one snapshot per minute, and size caps (10 MB per file, 200 MB per snapshot by default) keep a stray binary from bloating the repository.

{
  "xynorash/xyno-history.nvim",
  event = "VeryLazy",
  opts = {},
}

xyno-clipboard.nvim: yanks that reach you

Over SSH or inside tmux, a yank lands on the wrong machine. This provider copies with OSC 52 and, when wl-copy is available, also syncs the local Wayland clipboard. It installs only when $TMUX, $SSH_TTY, $SSH_CONNECTION or $HERDR_PANE_ID is set, and falls back to scanning up to 16 parent processes for herdr, so a plain local session is left alone. Not the sexiest plugin of the nine, but my yanks finally arrive where they are going.

The Rust toolkit

The other five get a list instead of a section each (I know, I'm so lazy!). They share one base, xyno-rust.nvim, and install in this order:

xyno-rust.nvim: a per-project Cargo context shared with rust-analyzer and bacon-ls, a targets picker, an HTTP route picker
xyno-new.nvim: new binaries, libraries, workspaces and egui apps
xyno-imports.nvim: auto-import with ranked candidates and a per-project memory
xyno-crates.nvim: crates.io search, cargo add, feature toggling
xyno-macros.nvim: completion inside derive and helper attributes, macro_rules! signature help, :MacroExpand

lazy.nvim installs the dependencies for you. The plugins page has a complete spec.

What splitting taught me

The parts that looked independent were not. Extracting a plugin forces you to write down what it depends on, and a few things I thought were self-contained quietly needed something else. Writing a README for each also showed me which behaviours I could not explain in a sentence, and those were usually the ones that needed another look. (I started this config as a "quick" project. Narrator: it was not quick.)

Honest limits

Every plugin needs Neovim 0.12+.
They are developed and tested on Linux. Windows and macOS are unverified for most of them, and xyno-sandbox and xyno-clipboard are Linux only.
Test counts vary: xyno-history has 65 specs and xyno-guard has 39, run with nvim -l tests/run.lua.
All are at v0.1.0 (xyno-sandbox at v0.1.1), so expect rough edges.

xynorash / xynovim

xynovim: a personal Neovim 0.12 configuration for Rust on LazyVim: instant rust-analyzer and clippy diagnostics, nvim-dap debugger, test UI with coverage, git safety net. Inspired by JetBrains tools. Developed on Linux; Windows passes the portable parts in CI, macOS is not reliably green.

xynovim

A personal Neovim configuration for Rust, built on LazyVim and inspired by JetBrains' tools. Instant diagnostics, a debugger and test UI, a git safety net, and a test suite you can run yourself.

Website: https://xynorash.github.io/xynovim/ (with guides to the workflows below)

xynovim is a Neovim 0.12 configuration for Rust development. It adds instant diagnostics (rust-analyzer while you type, clippy through bacon-ls half a second later), a debugger (nvim-dap with codelldb), a test UI with cargo-nextest and coverage in the gutter, Cargo workspace, feature and crate helpers, and a git safety net (Local History, lazygit, diffview) to a LazyVim base.

Quick start

git clone https://github.com/xynorash/xynovim ~/.config/nvim
~/.config/nvim/scripts/bootstrap.sh

Then start nvim in a Cargo project (or in demo/netwatch) and run :checkhealth xynovim. This replaces your current Neovim configuration, so move ~/.config/nvim aside first if you have one. Prerequisites and the Windows and macOS status are under Install…

View on GitHub

If you try one, I would like to hear what breaks. I read every comment. Tell me what breaks, I have thick skin and a very good test suite. Do you run your coding agent in a sandbox, or trust it with your home directory?

A Neovim config for Rust that I test like software

Xynorash — Fri, 23 Oct 2026 09:17:37 +0000

I write Rust in RustRover at work, and I still use JetBrains tools every day. They are the reason I wanted a certain kind of editing experience in my own terminal: errors on screen while I type, a debugger that shows real values, a test tree, an undo history that survives my own mistakes.

So I built xynovim, a Neovim config for Rust on top of LazyVim. It is a personal, independent project, not affiliated with JetBrains, and this post is the short tour.

The real config on a small demo crate. Everything in this post was recorded from it, nothing is mocked up.

Two tiers of diagnostics

rust-analyzer answers while you type, with type errors in about 0.01 to 0.15 seconds. Clippy follows about half a second later (0.56 s median): bacon-ls runs it against a hardlinked shadow of your workspace on every buffer change, so lints show up before you save.

rust-analyzer, while typing.

Each message shows its first line inline. The full text, with the suggestion, is one keypress away.

A debugger with real values

nvim-dap with codelldb, a layout that suits Rust, and lldb's Rust formatters loaded automatically, so a String or a Vec shows its contents instead of {...}.

Stopped at a breakpoint: locals, call stack, console and inline values.

One feature set for both tiers

:RustContext lets you pick Cargo features and a build target once, and applies them to both rust-analyzer and bacon-ls, saved per workspace. No more one tool seeing code the other does not.

The inactive side is greyed out and the statusline is back to "clippy ok".

A safety net

Every save is snapshotted as a commit under a private git ref (refs/lochist/). A bad refactor, a bad rename or a bad evening is one picker away from being undone.

Local History, backed by plain git.

Macros and dependencies

Type a path into a crate that is not a dependency yet and xynovim hints at it, offers a code action, searches crates.io, lets you pick features and writes the dependency into Cargo.toml. It also ranks ambiguous imports, remembers your pick, and shows macro expansions.

The hint on an unknown crate.

Macro expansion in a read-only split.

The AI agent, on a leash

I am not a vibe-coder. I want an AI tool inside a setup I understand, so the 99 agent (Claude Code as the provider) runs inside bubblewrap with a restricted filesystem and hidden credentials, and a Local History snapshot is taken before every request. It fails closed: no working sandbox, no request.

It is a seatbelt, not a jail. The network stays open, and no real agent request is driven in the test suite. I would rather tell you that than let you assume otherwise.

Nine standalone plugins

The original parts of the config are now standalone MIT plugins, so you can take only what you want:

xyno-history.nvim: Local History on private git refs
xyno-sandbox.nvim: runs an agent in bubblewrap, refuses without it
xyno-clipboard.nvim: OSC 52 clipboard provider for tmux and SSH
xyno-guard.nvim: keeps auto-save off dependency sources and changed files
a Rust toolkit of five that share one base: xyno-rust.nvim, xyno-new.nvim, xyno-imports.nvim, xyno-crates.nvim, xyno-macros.nvim

All nine install with lazy.nvim and need Neovim 0.12+. The plugins page has a complete spec for the Rust toolkit and the install order.

Tested, and I mean it

"It feels fast" is an opinion, so the config ships with a suite you can run yourself: 906 passing checks across 32 spec files, one per feature area, in about six minutes on my machine. Each spec runs in its own headless Neovim with a hard timeout and an isolated state directory.

The runner on four of the spec files: 129 passed, 0 failed.

What it is not

It needs Neovim 0.12, and it is developed on Linux (Arch). Windows is exercised in CI, and macOS is not reliably green yet.
The agent sandbox is a seatbelt, not a jail.
The macros and dependencies work is tested headless, not driven by hand in a real terminal. The unknown-crate hint is deliberately conservative: a miss is better than a false hint.

The full list, with what I decided and why, is in docs/KNOWN_ISSUES.md.

Try it

git clone https://github.com/xynorash/xynovim ~/.config/nvim
~/.config/nvim/scripts/bootstrap.sh

The bootstrap script checks the prerequisites and installs the plugins at their locked versions. Then open the demo crate in demo/netwatch and poke around.

Site, with every recording and six guides: https://xynorash.github.io/xynovim