The thing about a terminal is that it's the purest interface we have — and also the blindest. You're working in a void. No sidebar, no breadcrumb trail, no spatial memory of where anything lives. And Daniel's feeling that friction hard right now.
It's the one thing that still makes me reach for a GUI, honestly. Not because I want to click around — but because I can't remember the path to the thing I was working on three hours ago.
So here's what Daniel's asking. He's living in the terminal all day, jumping between repos, running Claude Code from different working directories, and the specific pain point is this: without a graphical file manager, there's no persistent visual memory of where things are. His workaround is sparse aliases — make one up when a repo gets heavy use, hope he remembers it later. It doesn't scale, he forgets the ones he made months ago, and he has to decide in advance what deserves an alias.
Which is the whole problem with aliases, right? They're premeditated. You have to know a path is important before you need it.
What he actually wants is a favourites-and-recents manager that lives in the terminal. Mark repos as favourites, pull up recently opened paths — maybe scoped to a specific CLI — jump straight to one, ideally with shortcuts bound to the ones he uses constantly. So the question is: what does zoxide actually do, where does the frecency model fall short of that vision, what else is in this space, and — here's the fresh angle — do any of these tools account for agentic workflows where Claude Code or similar is deeply tied to the working directory?
That last part. That's the part nobody's talking about.
So what's the actual problem we're trying to solve here? It's not that cd is broken — it's that we're asking it to do something it was never designed for.
Right. Cd does exactly one thing: it changes your current working directory to whatever path you give it. It has no memory, no learning, no concept of favourites, no awareness of what you did yesterday or five minutes ago. The problem isn't cd. The problem is that humans have terrible spatial memory for absolute paths, and the terminal gives us zero visual scaffolding. So we build tools on top of cd to compensate for a cognitive limitation, not a technical one.
And Daniel's sparse alias approach is actually a perfect example of the cognitive load problem. He's manually building a mental map — one alias at a time — and the map decays faster than he can maintain it.
The map decays. That's exactly the phrase. And that's what frecency-based tools are supposed to solve — they build the map for you, and they update it automatically as your behaviour changes. But here's the thing: a map that only shows you the most-travelled roads isn't the same as a map where you've pinned your favourite destinations. Daniel wants both.
Let's start with the tool that's probably on your radar if you've looked into this space at all: zoxide.
Zoxide. First released in twenty nineteen by Ajeet D'Souza, written in Rust, and it's essentially a smarter cd. You install it, it wraps your cd command, and from that point on it tracks every directory you visit. Then instead of typing cd and a full path, you type z and a few letters — z myproj — and it jumps you to the directory that best matches those letters based on your history.
So it's building a database of everywhere I've been, and when I type a fuzzy match, it ranks the results by... what, exactly?
This is where the frecency model comes in. Frecency is a portmanteau of frequency and recency, and zoxide combines both into a single score. A directory you visited ten times last week has a lower score than one you visited three times today. The decay function is logarithmic — recent visits decay slowly at first, then faster as they age. So a directory you were in heavily two days ago still ranks high, but one you haven't touched in six months has basically fallen off the map.
Which means the database is self-pruning in a way. You don't have to clean it up — the stuff you stop using just fades.
And the fuzzy matching is surprisingly good. If you type z myproj, it matches against the full path — so slash home slash user slash projects slash myproject. If you type z my, it might match myproject but also my-other-thing, and the frecency score breaks the tie. If you type z myp, it narrows further. The matching is substring-based and case-insensitive, and it handles typos reasonably well.
So walk me through the decay with a concrete example. I've got a directory I visited ten times last week versus one I visited three times today. Which one wins?
Three times today wins, and by a lot. The logarithmic decay means that recency dominates for the first few days, then frequency starts to matter more as the recency score decays. A directory you visit once a day for a month will eventually outrank one you visited twenty times in a single day three weeks ago. It's designed to track your shifting attention — what are you working on right now, not what were you working on last quarter.
And that's clever, but it also surfaces the first shortfall against what Daniel wants. If I'm working in fifty repos — which is not unusual — the top five by frecency dominate the rankings, and the other forty-five become effectively invisible.
Yes. Zoxide has no concept of favourites. You can't pin a directory to always appear at the top of results. You can't say "this path matters regardless of how often I visit it." And you can't scope the database — it's one global list. So if you're switching between an auth refactor in one repo and a UI bug in another, zoxide treats them as two entries in the same flat list with no relationship to each other and no task context.
Daniel specifically asked about scoping to a particular CLI or task. Zoxide doesn't even have the vocabulary for that.
It doesn't. And that's not a criticism of zoxide — it was never designed to do that. It's a smarter cd, not a context-aware workspace manager. But it's worth being precise about what it is and isn't, because a lot of people install it and think they've solved the favourites problem. They haven't. They've solved the "I can't remember the exact path" problem.
So zoxide is a smart search engine, not a favourites manager. What about the older lineage? Z, autojump, fasd — these all predate zoxide. Are they solving the same problem in a slower wrapper?
Z was the first one to really popularize frecency. Released in two thousand nine by someone who goes by rupa, written entirely in shell script. It works — it tracks your directories, builds a frecency database, and lets you jump with fuzzy matches. But because it's pure shell, it gets slow on large histories. Every time you cd, it has to read and write a flat file, and the matching is done with shell string operations. It's elegant in its simplicity, but it doesn't scale.
And autojump?
Also two thousand nine, by Joël Schaerer, written in Python. Autojump uses a weighted frequency model rather than true frecency — it's closer to pure frequency with a recency modifier bolted on. It runs a Python daemon in the background, which makes it heavier than z but also more accurate for some usage patterns. The key difference is that autojump's algorithm weights directories by the number of visits, with a decay factor applied as a separate step, rather than computing a unified frecency score. It's a subtle difference but it means autojump is slightly better at remembering directories you visit in bursts and then abandon.
And then fasd comes along and says "what if we did this for files too?"
Fasd, twenty thirteen, by Clément Farabet. It tracks files and directories together, and it gives you quick aliases — v for opening a file in vim, o for opening with the default application, and so on. The idea was that your most-used files and directories should both be one fuzzy search away. It's a genuinely good idea. The problem is fasd has been unmaintained since twenty fifteen. It still works on most systems, but it's frozen in time.
All three share the same fundamental gap though, right? No favourites, no scoped recency, no shortcuts.
None of them. They all answer the question "where have I been most often recently?" and none of them answer "where do I want to go right now, regardless of my history?" They're all search engines. Daniel wants a bookmarks bar.
Before we get to the tools that might actually give him that, what about the shell-native options? CDPATH, pushd, named directories — these have been around forever.
CDPATH is the simplest. You set it to a list of directories — usually your home directory and maybe a projects folder — and then when you type cd myproject, the shell searches those directories for a match. It's like PATH but for cd. Useful, but entirely manual. You have to decide what goes in CDPATH, and it never learns. It also only searches one level deep by default, so cd myproject works if myproject is directly inside one of your CDPATH entries, but cd myproject slash src doesn't.
So it's an alias with slightly less typing.
Pushd and popd and dirs are more interesting. They give you a stack of directories. Pushd changes to a directory and pushes it onto the stack. Popd pops the top off and changes back. Dirs shows you the whole stack. This is useful for linear workflows — you're in repo A, you need to check something in repo B, you pushd to B, do your thing, popd back to A.
But it falls apart when your workflow isn't linear.
Completely. If you're jumping between three or four repos in no particular order, the stack model is the wrong abstraction. You end up with a stack that doesn't reflect what you actually want, and you're constantly rearranging it. And then there's zsh named directories — hash dash d — which is actually the closest shell-native equivalent to what Daniel wants.
How does that work?
You run hash dash d myproj equals slash home slash user slash projects slash myproject, and from then on, tilde myproj expands to that full path. You can cd tilde myproj from anywhere. It's essentially a named bookmark. But — and this is the same problem as aliases — you have to set them up manually, they don't learn, and you forget which ones you've defined.
So everything we've covered so far is in the "make cd smarter" category. None of it is a favourites-and-recents manager. What about the tools that try to bridge terminal and GUI — the ones that give you a visual map?
So zoxide is great at making cd smarter, but it's not a favourites manager. What about the tools that try to give you a visual map of the filesystem?
This is where broot, yazi, and nnn come in. These aren't trying to make cd smarter — they're trying to give you a file manager inside the terminal.
Broot, by someone who goes by Canop, written in Rust. It's a tree-view explorer. You run br, it shows you the directory tree starting from your current location, and you can navigate with arrow keys, filter with fuzzy search, and when you select a directory and hit enter, it outputs a shell command that cds you there. The br shell function captures that output and executes it.
So it's visual browsing, not jumping.
You see the tree, you navigate to what you want, you select it. It's closer to a GUI file manager than to zoxide. And it's good at what it does — the fuzzy filtering is fast, the tree view is clean, and it handles large directories without choking. But it's a different interaction model. You're browsing, not jumping. If you know exactly where you want to go, broot is slower than just typing z myproj. If you don't know where you want to go — or you want to see what's in a directory before you decide — broot is better.
And yazi?
Yazi, by sxyazi, first release twenty twenty-three, also in Rust. It's a full terminal file manager with a vim-like interface — you navigate with h j k l, you can preview images, it does async I/O so it doesn't block on large directories. It's impressive technically. But again, it's a file manager. You browse, you don't jump. The "cd on quit" functionality means when you exit yazi, it changes your shell's working directory to wherever you navigated — so it can function as a navigation tool. But it's designed for exploring and managing files, not for jumping to a known path in under a second.
And nnn is the minimalist entry in this category.
Nnn, by jarun, written in C, first release twenty sixteen. It's tiny — the binary is something like sixty kilobytes — and it has a plugin system for extending functionality. It also supports cd on quit. It's the tool you use when you want a file manager that stays out of your way. But like broot and yazi, it solves the "no visual memory" problem by giving you a visual tree. It doesn't solve the "I know where I want to go and I want to get there instantly" problem.
So these are complementary to zoxide, not replacements. When you can't remember the path, you browse. When you know the path, you jump.
Right. And Daniel's prompt is specifically about the jumping case — he wants a favourites-and-recents manager that lets him jump to known paths quickly. The visual tools are useful but they're solving a different problem.
Then there's the fzf-driven picker approach. This feels like it could bridge the gap — fzf gives you the interactive selection, and you pipe a list of directories into it.
Fzf, by Junegunn Choi, first release twenty thirteen, written in Go. It's a general-purpose fuzzy finder — you pipe any list into it, it gives you an interactive filter, and it outputs whatever you select. The classic naive approach is cd dollar paren find period type d pipe fzf — but that's slow because find has to walk the entire tree, and it's unscoped because it shows you every directory recursively.
So you use fd instead of find.
Fd is faster and respects gitignore by default, so you're not wading through node modules. But even with fd, you're still doing a live search every time, which means you're waiting for the filesystem walk. The smarter approach is to integrate fzf with zoxide — z dash i gives you an interactive fzf interface over zoxide's database. Now you're searching your history, not the filesystem, and it's instant.
Zoxide builds the database, and fzf provides the interactive picker on top. That starts to look like a recents list.
It does. But it's still a single global list. No task scoping, no favourites, no pinned directories. Fzf is a UI layer — it doesn't know anything about what the list means. It just displays whatever you pipe into it and lets you fuzzy-filter. The intelligence has to come from whatever builds the list.
Which brings us to the agentic angle. Daniel's using Claude Code throughout the day, and Claude Code is deeply tied to the working directory. You run it from a specific directory for a specific task.
Claude Code, released by Anthropic in twenty twenty-five. You invoke it from a terminal, and the directory you're in when you run it becomes its working context. It reads files relative to that directory, it runs commands in that directory, it understands the project structure from that directory outward. The CWD is baked into how it operates.
And that changes the requirements for directory navigation in ways that none of these tools account for.
In three specific ways. First, you need to switch directories frequently and reliably between agent sessions — not just within a single shell session. If you finish an auth refactor in repo A, close Claude Code, and open it in repo B for a UI fix, that directory switch has to be fast and deterministic. You can't afford to mistype and land in the wrong directory, because the agent will start operating on the wrong codebase.
Second?
You need to scope navigation by task or project. Daniel's prompt mentions this — he wants to pull up recently opened paths scoped to a specific CLI or task. "Take me to the directory where I was working on the auth refactor" is a query no current tool can answer. Zoxide knows you were in repo A, but it doesn't know why. Fzf can show you the list, but it can't filter by task context. Broot can show you the tree, but it doesn't track your sessions.
And the third way?
You need to share directory context between the human and the agent. If Claude Code is running in repo A, and you switch to repo B in another terminal, the agent in repo A doesn't know. If you want to tell the agent "I'm moving to repo B to fix the login button, adjust your context accordingly" — there's no mechanism for that. The working directory is a coordination primitive between human and agent, and none of our current tools treat it that way.
The working directory becomes this implicit signal that both sides are reading, but neither side is explicitly managing.
Yes. And that's the gap. Right now, the working directory is just where you happen to be. With agentic tools, it should be a deliberate choice that carries meaning — "I am in this directory because I am working on this task, and the agent should know that." No current tool supports that.
Is this a gap worth building into? Or is it the kind of thing that sounds important but in practice nobody would use?
I think it's worth building into, and I'll tell you why. As agentic tools become more common, the working directory stops being a convenience and starts being a coordination mechanism. The directory you're in tells the agent what task you're working on, what context to load, what tools to use. If you're in the wrong directory, the agent does the wrong thing. Fast, reliable, scoped directory switching isn't a nice-to-have — it's a core UX requirement for human-agent collaboration.
None of the tools we've discussed were designed with that in mind. Zoxide was designed for a human browsing a filesystem in twenty nineteen. Fzf was designed for general-purpose fuzzy finding in twenty thirteen. Broot and yazi and nnn were designed for visual file management. The agent wasn't a consumer of directory context when any of these were built.
Right. And you can see the shape of what a next-generation tool would need. It would need task-scoped recency — "show me the directories I used while working on the auth refactor." It would need agent-aware navigation — "tell the agent I'm moving to repo B and why." It would need shared favourites between human and agent — "pin repo A as the primary workspace for this project." And it would need shortcut bindings for the paths you use constantly, scoped to the current task context.
Daniel mentioned wanting shortcuts bound to frequently used paths. That's the one piece that's actually achievable today with shell-native tools — named directories give you tilde shortcuts, and you can bind those to whatever keys you want in your shell config. But again, it's manual.
It doesn't share with the agent. The agent doesn't know about your named directories. The agent doesn't know about your aliases. The agent only knows the absolute path you gave it when you launched it.
Where does that leave us? If you're a terminal-first developer using agentic tools, what should you actually do today?
Three things. First, use zoxide as your default cd replacement. It's the best of the smarter-cd tools — fast, written in Rust, good fuzzy matching, actively maintained. Install it, let it learn your habits, and use z to jump. But pair it with fzf for interactive selection — z dash i gives you the recents list with fuzzy filtering. That covers the recency case.
And for favourites?
Use zsh named directories — hash dash d — for the paths you use constantly. Pin your top five or ten repos with short names. Tilde myproj is faster than z myproj because it's deterministic — no fuzzy matching, no database lookup, just expansion. And you can use those named directories in any command, not just cd. That covers the favourites case.
Zoxide for recency, named directories for favourites, fzf for interactive selection. That's a workable stack.
It is. Second, for visual navigation, use broot or nnn as a complement, not a replacement. When you can't remember the path and you need to browse, br or nnn gives you the tree. When you know the path, z or tilde myproj gets you there instantly. The two modes are complementary. Don't try to make one tool do everything.
And third?
If you use agentic tools like Claude Code, be aware of the gap. No current tool supports task-scoped or agent-aware navigation. The best workaround today is to use shell functions that log directory changes with a task label. Something like cd hyphen auth that changes to repo A and tags it as "auth refactor" in a simple log file. Then you can grep that log to find directories by task. It's hacky, it's manual, it's not integrated with anything — but it's functional until something better exists.
A shell function that wraps cd and writes to a dotfile with a timestamp and a tag. It's not elegant, but it's maybe twenty lines of bash.
That's the thing about the terminal — the composability means you can prototype the thing you wish existed in an afternoon. The gap is real, but the workaround is achievable.
But there's a bigger question here that I want to leave you with.
Go on.
Will the next generation of directory navigation tools be designed for human-agent collaboration — task-scoped, agent-aware, with shared context between human and agent? Or will agents eventually learn to navigate independently, making the human's navigation tools irrelevant?
That's the fork in the road. If agents get good enough at understanding project structure from any starting point, the working directory stops mattering — you just tell the agent what you want and it figures out where to operate. In that world, all of these tools become obsolete, because the agent is doing the navigation, not you.
But we're not there yet. And in the meantime, the working directory is a coordination primitive that we're barely using.
The tools we have — zoxide, fzf, broot, the whole lineage — they're all designed for a world where the human is the only one navigating. They're good tools. Zoxide in particular is excellent at what it does. But they weren't built for the world Daniel is living in, where an agent is sitting in one directory waiting for context while the human is jumping between five others.
The terminal is a pure interface. But purity doesn't mean simplicity. The best tools are the ones that disappear into your workflow. Zoxide gets close for the human. The agentic future demands something more.
If you're a tool builder listening to this — the gap is real. A favourites-and-recents manager with task scoping, agent awareness, and shared context between human and agent would be novel. Nobody's built it yet.
Thanks to our producer Hilbert Flumingtop for making this episode happen.
This has been My Weird Prompts. If you enjoyed this episode, leave us a review — it helps other terminal-first developers find the show.
We'll be back soon.
