Seven tools, in the order I tried them, with the specific reason each one lost. Number one: the browser bookmarks, the default, and the failure is the search — a bookmark is a URL, and the code is on the page, and the retrieval is a five-minute re-derivation instead of a two-second copy. Number two: the notes app, the failure is the format — code in a notes app is text, not code, and the copy brings the formatting with it, which is a bug in every paste. Number three: a dedicated snippet SaaS, the failure is the trust — the snippets contain secrets, and the secrets are on a vendor's servers, which is the deal-breaker that ended the category for me, and the deal-breaker is the part of the article that transfers to every other storage decision you will make.
Number four: the editor's built-in snippets, the failure is the scope — the snippets live in the editor, and the work happens in the terminal, and the two never meet, which is the failure of every tool that owns one surface of the workflow. Number five: a plain text file, the failure is the search — it works until the file is two thousand lines, and then it is a grep exercise every time, and the grep exercise is the tax. Number six: a markdown knowledge base, the failure is the friction — the capture is a window switch, and the window switch is where the habit dies, because the habit dies at the window switch, not at the storage. Number seven: the terminal manager, the one that stayed, and the reasons are the article. The pattern across all seven: the tool that owns the capture moment wins, and the capture moment is in the terminal, which is the finding the list exists to support, and the seven failures are the evidence for it.
Lists are a lazy format, and a lazy list is worse than no list, because it costs you ten minutes and gives you nothing. So this one is built to a standard: every item has what it does, when you would actually use it, and the specific failure it prevents. No filler, no and-more. No item that exists only to pad the count. snippetx is the lens — Terminal code snippet manager: save, search, and copy snippets with six commands. Local-first, zero dependencies. — and the list below is the part you can screenshot and keep. If an item does not save you a specific amount of time or a specific kind of pain, it is not on the list, and the items that are on it are ordered by how often they actually earn their place.
Search That Finds the Right Snippet
A snippet collection is only as good as its search, because the failure mode of a bad search is: I will just rewrite it. The tool searches by term across snippet names and content, and the list command filters by language, so the two together cover the two ways you actually recall a snippet: by what it is — a route, a regex, a deploy script — and by what it is made of — the framework, the command, the config key. The search is exact and fast because the corpus is small and local: hundreds of snippets, not millions, and no network round trip. The practical test is the ten-second rule: if finding the snippet takes longer than rewriting it, the tool has failed. On a well-named local collection, finding beats rewriting in most cases, and that gap is the entire value. The naming is the skill, and the skill is cheap: name the snippet for the job it does, not the project it came from, and the job outlives the project. The search finds jobs; that is what makes the collection compound instead of rot.
Snippets as a Second Brain for Code
The habit that makes a snippet manager pay for itself is capture-at-discovery: the moment you solve a problem, the solution gets saved, named, and tagged, in the same motion as the solve. Not later. Not: I will organize my snippets on the weekend. The weekend version never happens, and the value of a snippet decays fastest in its first week, when the context is still fresh and the name is still obvious. Capture-at-discovery turns snippets into a second brain: a store of your past decisions that is searchable at the moment of need. The tool is the easy part; the habit is the product. But the tool has to make the habit costless — one pipe, one name, one tag — or the habit will not form. The cost has to be lower than the cost of the next time you need it, and the next time is always sooner than you think. A second brain for code is not a collection; it is a reflex, and the reflex is built from the same six commands, run in the same order, every time a problem gets solved. Consistency is the compounding.
When a Snippet Manager Is Overkill
Honesty section: if you have fewer than fifty snippets and your editor already stores your common ones in its own snippet system, a dedicated manager is not worth the switch. The editor built-in is where your fingers already go, and adding a second system creates a split brain — half your snippets in the editor, half in the CLI, and you never remember which. The CLI tool earns its place when the snippets outgrow the editor: when they contain multi-file configs, shell scripts, and language-mixed content; when you want them searchable from the terminal where you actually work; when you want them under version control with a team. The right question is not: should I use a snippet manager? It is: has my collection outgrown where it currently lives? Answer that honestly and the tool takes care of itself. The outgrowth is usually visible as a specific moment — the third time this month you could not find the thing you knew you had written — and the moment is the signal, not the count. The count is what you check after the moment has already happened twice.
The 30-Minute-a-Day Math
Time to verify: how often do you re-derive code you have written before? The honest answer for a working developer is several times a day — a config block, a shell pipeline, a regex, a deploy command. Each re-derivation costs a few minutes at best and a few hours at worst, when the quick version has a subtle bug that the original had fixed. If the average is even fifteen minutes a day, a snippet manager that cuts that in half is worth a full workday a month. The tool is a few seconds of setup; the payback is measured in hours per quarter. I am not claiming precision here — the point is the order of magnitude. Any tool that saves thirty minutes a day is not a toy, and the snippet manager is one of the few where the math is that straightforward, because the cost of the alternative is visible in your own calendar: the afternoon you spent rewriting the deploy script you wrote last spring, the hour you spent re-deriving the regex you could have searched for. The math does not need to be exact to be decisive.
Six Commands, Whole Workflow
The tool has six commands and that is the entire surface: add, list, show, search, rm, copy. add saves a snippet with a name and an optional language tag, reading the content from stdin. list shows what you have, filterable by language. show prints one snippet by id. search finds snippets by term, in names and content. rm deletes. copy prints a snippet to stdout so you can pipe it to your clipboard. There is no account, no project, no workspace, no sync layer. The design bet is that a snippet tool only has to answer one question — what did I write before, and how do I get it back into my editor fast — and that answering it in six commands is a feature, not a limitation. Every extra concept is a reason to stop using the tool. The surface is small enough to learn in the first session, which means the habit can form in the first week, and the habit is the product. The six commands are the entire API, and the API is the design.
Zero Dependencies, Instant Startup
The tool is a single file with no runtime dependencies, and the consequences are the same as in every other tool in this family: npx runs it without a global install, startup is instant, and there is no dependency tree to audit. For a tool that is part of a keyboard-driven workflow, startup latency matters more than it sounds. A snippet command that takes three seconds to respond breaks the flow; one that responds before you finish the pipe does not exist as an experience. Zero dependencies is the engineering answer to that requirement, and it also means the tool works in the same places your shell works — containers, CI, restricted machines — without a setup step. Small, fast, and present: the whole design in three words. The presence is the point. A tool that is always available and always instant stops being a tool and starts being a surface, the way the shell itself is a surface, and the snippets live on that surface the way everything else in the workflow does.
Snippets Contain Secrets: The Local-First Argument, Quantified
Here is the uncomfortable truth about snippet managers: snippets are where secrets go to hide in plain sight. A debug snippet from last month contains the API key you used. A deploy script snippet contains the database URL. A quick-test snippet contains the token you copied from the console. In a cloud snippet manager, those values are on a vendor's servers, in their backups, in their support logs, and in their terms of service. In a local file, they are on your machine, under your control, scannable by a secret scanner, and rotatable without a vendor. The privacy argument for local-first is not hypothetical; it is the specific, documented habit of developers pasting live credentials into their notes. Your snippets should live where your secrets can live — which is to say, where you can find them, scan them, and rotate them. The local file makes all three of those possible; the cloud file makes all three of them someone else's problem. That is the quantified argument, and it is the one that survives contact with a real codebase.
The Copy Pipeline Across Three Operating Systems
The last mile of a snippet workflow is the clipboard, and the clipboard is where tools get platform-specific. The tool keeps its side of the contract simple: copy prints the snippet to stdout. The rest is the shell. On macOS, pipe to pbcopy. On Windows, pipe to clip. On Linux, pipe to xclip or xsel depending on your desktop. One command per platform, three lines of muscle memory, and the snippet lands in your editor without a single mouse movement. The design deliberately does not try to own the clipboard — it would have to shell out to something platform-specific anyway — it just makes the contract so clean that the platform part is a two-word suffix. The workflow feels seamless because the tool knows exactly where its job ends. That boundary discipline is the quiet feature: the tool is a pipe segment, not a platform, and pipe segments compose with everything else you already have, which is why the whole pipeline feels like one command even though it is three.
Sharing Snippets With a Team (Without a Server)
The team use case is the one that looks like it needs infrastructure and does not. A snippet collection is a directory of text. Sharing it is a git repository: every developer pulls the shared snippets, adds their own to a shared folder, and the review of a snippet is a normal pull request. There is no server to run, no permission model to design, no sync to debug. The git history gives you something a hosted service would charge for: who added what, when, and why, reviewable. The tradeoff is that the team has to agree on naming conventions, which is a conversation, not an engineering problem. For a team of five to fifty, a git-backed snippet library is the boring, durable answer, and the tool is the reader and writer that makes it a workflow instead of a file convention. The pull request is the onboarding: a new developer reads the repository and inherits the team's past decisions, which is the closest a team of developers gets to a shared memory, and it is versioned, so it cannot quietly rot the way a wiki can.
Pipe In, Pipe Out: The Unix Way
The interface is pipes, which is where the power is. Save: pipe the content you just wrote into add, with a name and a language — the snippet is captured in the same motion as the moment you wrote it, no window switching. Retrieve: search, pick the id, pipe copy into your clipboard, and the snippet is on your clipboard before your hand leaves the keyboard. The pattern generalizes to anything: the output of a command you just ran, a block of config from a man page, a JSON response from a test. The tool does not try to be an editor or a note app. It is a pipe between your terminal and your future self, and pipes compose. That is the difference between a snippet manager you visit and one you live in. Visiting requires intent; living requires only the next pipe. The capture cost is a keystroke and a name, and the retrieval cost is a search term, and both costs are low enough that the habit is cheaper than the alternative, which is remembering. The alternative always costs more, eventually.
The Snippet Scattering Problem
Your code snippets do not live in one place. They live in four browser bookmarks, the notes app on your phone, a scratch file you never cleaned, the README of a project you will not open again, and your memory, which is not a storage system. The result is a tax on every small task: the regex you wrote twice last year, the shell one-liner that took twenty minutes to debug, the config block that is correct in exactly one way. You do not search for it; you rewrite it, and the rewrite is eighty percent correct and the other twenty percent is where the bug lives. A snippet manager is not a productivity fantasy. It is a fix for the specific, measurable cost of re-deriving code you have already derived. The question is only where it should live — the browser, the cloud, the notes app, or the terminal — and the answer depends on where the capture moment happens, which for working developers is, almost always, the terminal. The rest of this article is the argument for that answer, built from the six commands that implement it.
The takeaway
That is the list. Screenshot it, pin it, or just remember the three items you will actually use — that is the honest success metric for a list. The tools behind it: npx @wuchunjie/snippetx, source at https://github.com/wuchunjie00/snippetx, and the same npx pattern for the rest of the toolkit. If the list saved you a specific amount of time, ko-fi.com/wuchunjie is a one-click thank-you that keeps every tool free and dependency-free. The next list is already forming, and the items that fail the specific-pain test will not make it. A list that only contains things worth keeping is the only kind of list worth publishing, and that is the standard this one was held to.
Top comments (0)