FanBox: A macOS Cockpit for Watching Coding Agents Edit Local Files
vibe coding 的驾驶舱：左边文件，右边/下边终端，中间看清每一次改动。 / The cockpit for vibe coding: browse files on the left, command agents on the right, watch every change in between.
At a glance
- What is it?
- FanBox is an Electron shell that pairs a file browser with an embedded real terminal, then highlights every file an agent writes. It is built for the loop of finding a project, running Claude Code or Codex in it, and seeing what changed, all in one window.
- Who is it for?
- Adopt FanBox if you run Claude Code or Codex from a terminal on macOS and keep losing track of which folder a session touched. Skip it if you work primarily in an IDE, need Windows or Linux as a first-class target, or want a hosted or remote development environment, since the project is local-only by design and the Windows build is described as a community port.
- Can I use it commercially?
- Yes. MIT is a permissive licence: you can use, modify and sell software built on it, as long as you keep its copyright and licence notices.
- Is it still maintained?
- Yes. The repository last received commits 12 days ago.
- What is it written in?
- Mainly JavaScript, according to GitHub's language statistics.
Answers come from the project's GitHub data, last synced on September 15, 2026, and from our analysis. They are not legal advice.
DEEP OPEN-SOURCE ANALYSIS
The problem FanBox picks: ten projects an afternoon, none of them findable
The README states the premise directly: an AI can help you start ten projects in an afternoon, and then they scatter, the names stop making sense, and you cannot see what got changed. The claimed daily routine is digging through Finder, switching to iTerm to launch an agent, then switching to a browser to check the result. FanBox exists to collapse that three-window hop into one window.
The audience is narrow and worth naming. This is for someone who already runs a coding agent from a shell, on macOS, and who cares more about locating a folder and inspecting the agent's output than about editing code in a full IDE. The README is explicit that FanBox does not compete with Finder on file operations or with VS Code on editing. It positions itself on one chain: find, preview, light edits, command the agent. If your work is mostly typing inside an editor, the product's own framing says you are not the target.
Two panes and a write signal: the mechanism behind the cockpit
The layout is the mechanism. Files sit on the left, the terminal sits on the right or the bottom, and preview happens in place. The project describes itself as a no-build runtime, and it is an Electron application distributed as a dmg for Apple Silicon. No cloud, no remote, no accounts, and the README claims zero runtime dependencies.
The interesting part is the change signal. According to the README, every time the agent writes a file, that file's card ripples and then glows in proportion to how often it has been changed, so the light follows the agent as it moves through the tree. Follow mode extends that: the file view and the preview track whichever file the agent is currently editing, with freshly written lines flashing in code, HTML rendering as a live page while it is being written, and Markdown rendering live. The README says the HTML path is double-buffered to avoid a white flash. Any manual browsing immediately returns control to you.
A second panel, called This round in the README, groups the files an agent changed by which terminal and which agent made the change, with per-file line counts. Clicking a row opens a side-by-side diff in Monaco. You can restore a single file, roll back the whole round, or scrub a draggable replay timeline. For Markdown the comparison is the rendered reader view rather than the source, and for images there is a before and after slider. That last detail is the clearest statement of intent in the whole document: the thing being reviewed is the artifact, not only the diff.
Finding a folder, previewing it, and resuming an agent session
The file side is built around a global fuzzy search bound to Cmd+K. The README says a name fragment is enough, that Cmd+Enter opens the project in your editor, and that a content: prefix switches the search to full text. Folder cards carry node, web, py, rs or go badges, which is a small feature aimed squarely at the ten-projects problem.
Preview is inline and covers more formats than you might expect: rendered Markdown, live HTML, syntax-highlighted code, images, video, PDF, HEIC images, archive content listings, and a checkerboard backing for transparent images. The README claims scrolling and clicking through large folders stays under 0.1 seconds. That figure is a claim from the project's own documentation, not something I measured.
The feature that ties the two halves together is project memory. Opening a project folder shows past sessions, using your first message as the session title, the files each session changed, and any skills that were triggered. A resume control then runs claude --resume or codex resume inside the embedded terminal to pick the context back up. This is the piece that turns a file browser into something specific to agents rather than a general-purpose Finder replacement.
There is also a comment-and-feed-back path: select lines in a diff, write a note, and it is pasted into the originating agent's terminal as a file:line reference plus a fenced code block plus your note, using bracketed paste and deliberately not pressing Enter. You submit it. That restraint is the right call, since an auto-submitted paste into a running agent is a good way to lose work.
Installation, skins, and the update path
The README points at the releases page for a dmg download and labels the platform as macOS on Apple Silicon. Windows is listed with a badge reading community port, which is a meaningful distinction: it is not presented as an officially supported target in the same way. The install section of the README is referenced in the table of contents but the supplied text does not include its body, so I cannot state the exact steps beyond downloading from the latest release.
Three skins ship: Volt, the default, described as neon green on charcoal with monospace type; Archive, described as cream paper with terracotta and serif type; and Index, described as black and white with signal red and green and oversized type. The README is careful to say these are not theme-color swaps, and that palette, typography, icons, code highlighting and terminal ANSI themes all change together. The UI was designed with the author's huashu-design project.
Updates are handled in-app as of v2.16.0, which the release notes describe as downloading in the background and swapping in on restart. v2.16.1 followed the same day with a fix for a race condition in the update button introduced by 2.16.0. That sequence is worth reading carefully. A one-click updater is a convenience, but it is also the component that can leave you on a half-updated build, and the back-to-back releases suggest the first version of the mechanism had a visible defect.
Where FanBox is the wrong tool
The README's own scoping is the first limitation. It does not try to match Finder on file operations or VS Code on editing. If you need refactoring tools, multi-file search and replace across a repository, language server diagnostics, or a debugger, none of that is described here, and you would be running two applications to get one job done.
The platform constraint is the second. macOS on Apple Silicon is the supported target; Windows appears as a community port. Linux is not mentioned in the supplied material at all. If your team is not on Macs, the project does not currently claim to serve you.
The third is subtler and comes from the design itself. FanBox watches files the agent writes and lights them up. That signal depends on the agent writing files through the filesystem in a way the watcher can see. The README does not describe how it detects changes, so I cannot say whether it uses filesystem events, polling, or a diff of snapshots, nor how it behaves with very large trees, with changes made outside the watched project, or with an agent that writes through a remote or containerized filesystem. Anyone whose agent runs inside Docker or on a remote host should treat the change dashboard as unverified until they try it.
Finally, the local-first stance is a boundary, not a flaw. No cloud, no remote, no accounts means no sync between machines and no shared session history across a team. If you want a hosted workspace where a colleague can pick up the same agent session, this is the opposite of that.
The realistic alternative, and the actual difference
The obvious alternative is running the agent in a terminal emulator such as iTerm and browsing files in Finder, which is exactly the workflow the README opens by describing. The difference is not cosmetic. In that setup, the connection between a changed file and the agent that changed it lives in your head, or in git status. FanBox replaces that with a grouped panel that attributes each changed file to a specific terminal and agent, and keeps a per-round record you can scrub through. iTerm plus Finder gives you more power in each half and no connection between them; FanBox gives you less power in each half and the connection built in.
A second alternative is an IDE with an integrated terminal, which covers the file tree and the shell in one window too. The distinction is what the window is optimized for. An IDE assumes the human is the primary writer and the terminal is a side panel. FanBox assumes the agent is the primary writer and the human is reviewing, which is why the diff, the rollback, the replay timeline, and the resume control are the headline features rather than the file tree. If you already live in an IDE and your agent runs in its terminal, you have most of the layout and none of the attribution.
A third comparison worth making is against plain git. Rolling back a round is something git can do. What git does not give you is a live view while the agent is still writing, or a rendered before-and-after for a Markdown file or an image. FanBox is not a version control system and the README does not present it as one; treat its round rollback as a convenience layered on top of whatever your repository already tracks.
Licence, maintenance, and what to check before adopting
FanBox is MIT licensed, which permits commercial use, modification, and redistribution provided the copyright notice and permission notice are included. That is permissive and low-friction for internal adoption. It is not legal advice, and if you plan to redistribute a modified build you should read the LICENSE file in the repository rather than rely on the badge in the README.
The maintenance picture visible in the material is active. The last push is dated 2026-09-03, and three releases landed on that same day: v2.15.2, v2.16.0, and v2.16.1. The release titles are in Chinese and describe a lid-close toggle returning to the sidebar, a scheduled task toggle fix, then the in-app updater, then the updater race fix. A project shipping three releases in a day is moving quickly, which cuts both ways. You get fixes fast, and you also get churn in the surface you depend on.
The upgrade cost is mostly the updater itself. Because v2.16.0 introduced the in-app download-and-restart mechanism and v2.16.1 was needed to correct a race in its button state, the safest path is to install a build at or after v2.16.1 rather than 2.16.0, and to confirm after the first in-app update that the version reported in the app matches the release you intended. Beyond that, there is no plugin ecosystem, no configuration file described in the supplied README, and no server component, so the operational surface is one Electron app and the agents you already run.
The one thing I would verify first is the change-attribution pipeline, because it is the entire reason to choose this over iTerm and Finder. Open a project, start a session in the embedded terminal, have the agent write several files including one Markdown file and one image, and check that the This round panel attributes each file to the correct terminal and that the Markdown comparison shows the rendered view. If that pipeline works on your projects, FanBox is doing something your existing tools do not. If it does not, you are left with a file browser and a terminal, both of which you already have.
Editorial conclusion
Adopt FanBox if you run Claude Code or Codex from a terminal on macOS and keep losing track of which folder a session touched. Skip it if you work primarily in an IDE, need Windows or Linux as a first-class target, or want a hosted or remote development environment, since the project is local-only by design and the Windows build is described as a community port. Before installing, verify two things against the release you download: that the dmg is signed and notarized for Apple Silicon, and that the in-app updater in v2.16.0 and later behaves correctly on your machine, because v2.16.1 was released specifically to fix an update-button race condition introduced in v2.16.0.
Community notes