Your AI coding agent can read your SSH keys. I built a Neovim plugin that won't start it unprotected A developer released xyno-agent-sandbox.nvim, a Neovim plugin that launches command-line coding agents inside bubblewrap with a read-only filesystem, empty credential directories such as ~/.ssh and ~/.aws, stripped secret-like environment variables, and read-only git directories, refusing to start the agent if no sandbox can be created. It is one of nine standalone MIT-licensed plugins extracted from the developer's xynovim Rust configuration, all requiring Neovim 0.12+. The developer notes the sandbox is a denylist on a read-only view with network access still open, describing it as "a seatbelt, not a security boundary against a determined attacker. 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 https://github.com/xynorash/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/