ai newsFr., 30. Okt.
EilmeldungCursor Marketplace vs. Official Claude Code: What Version 2.1.313 Reveals

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

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 t

dev.toFreitag 12:13 · 30.10.4 Min. Lesezeit
Bild: dev.to

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).

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.

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.

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 = {}, } Enter fullscreen mode Exit fullscreen mode 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 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:

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

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.)

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.

git clone https://github.com/xynorash/xynovim ~ /.config/nvim ~ /.config/nvim/scripts/bootstrap.sh Enter fullscreen mode Exit fullscreen mode 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 …

Quelle: dev.to (dev.to). Original öffnen