Shell history is the oldest memory system most of us own, and it is the worst one we tolerate.
I have spent this week arguing here that the real problem with AI tooling is memory that does not survive a session. Then I looked at my terminal and realised the argument had been sitting in front of me the whole time. Shell history is the memory system every developer already owns. It has been running for decades. By default it is worse than anything we would ship today. A flat file. No context. Truncated at some arbitrary line count. Gone when you switch machines. It records what you typed and throws away everything that made it meaningful: which directory you were in, whether it worked, how long it took. We would never accept this from a new product. A notes app that stored notes without dates, silently dropped the oldest ones, and did not sync would get laughed off this site. Shell history gets a pass purely because it has always been that way, so nobody counts it as a memory system at all. It is just there, quietly useless. What changes when you fix it is not storage, it is the question you can ask. "What did I run in this repo that actually worked" is a different question from grepping a text file, and it is the question you actually have. Exit codes turn a log into a filter. Directory context turns global noise into per project memory. Duration tells you what was expensive. So the claim: most memory problems are not storage problems, they are context at write time problems. The data was there. Nobody kept the fields that would have made it findable later. What is the one field your history does not keep that you would actually use?
Replies
This is a great analogy .We've normalized terrible shell history don't even think of it as a memory system anymore.
I agree that storage is rarely the real problem. Context is what makes memory valuable. If you could only keep one extra field I would choose the working directory because almost every command depends on where it was executed.