The Story of Why I Built ghfs

I usually develop software alongside Generative AI (specifically Claude Code). My workflow involves using GitHub Issues as a unit of task management. I have Claude Code read an issue, investigate the scope of impact, report on the implementation plan, and then proceed with the actual implementation.

When passing the content of an issue to the AI in this workflow, I use the gh command. The AI "knows" how to use the gh command. However, it frequently uses non-existent options or makes incorrect guesses that lead to errors, requiring corrections and retries. These are wasted steps.

This could be corrected using rule files (prompts). But rule files should be for project-specific instructions. Writing instructions for how to use general-purpose tools felt like the wrong responsibility for a prompt. I felt that putting effort into that was a futile endeavor.

Just Make It a File

This might be controversial, but I do not believe in MCP servers. They just add more uncertainty to the already uncertain behavior of Generative AI.

A file system is the same on every OS. Reading a file, running grep—these are things even Generative AI can execute reliably.

Furthermore, I believe that with the advent of Generative AI, there is an advantage to monolithic repository management. Having all the information necessary for a project contained within that repository or workspace is beneficial for providing context to the AI.

So, I thought: what if GitHub Issues were visible as local files? That is why I built ghfs.

What is ghfs?

ghfs is a tool that mounts GitHub Issues as a local file system using FUSE. It is written in Go and supports macOS and Linux.

I made it read-only. This tool is built on the premise that Generative AI will interact with it; human interaction is only a secondary benefit. I wanted to avoid situations where the AI might update an issue without permission. Even if you set up guardrails, you never know if they will work perfectly. Unintended behavior is a problem for personal projects and even more so for professional work. By making it read-only, I can guarantee at the file system level that nothing will be destroyed. By the way, having issue content show up in an IDE's full-text search is unexpectedly convenient for humans too.

It does not sync in real-time. Just like how code committed or merged by someone else on GitHub doesn't automatically appear on your local machine, I provided a command to fetch updates manually. I can't imagine a requirement where issue content must be reflected in real-time, and trying to achieve that would mean worrying about GitHub API rate limits.

I chose Go because I wanted it to be multi-platform. While I usually only work on a Mac, if I am going to use Generative AI more in the future, it is better if the tool works on Linux and Windows as well.

Why Is It Paid?

I have long watched the owners of open-source software (OSS) become exhausted. I have never released anything as OSS myself, but I felt that because OSS has become so closely tied to social networking, the purpose and means of a product can become messy.

And above all, you cannot live without money.

Who Is It For?

People who work based on issues. Or people who can embrace such a workflow.

Simply put, it can act as a substitute for a human opening GitHub in a browser, or a substitute for an AI running gh commands. It comes down to whether you find value in that.

I designed ghfs so that additional providers can be implemented, so I plan to support services other than GitHub in the future. It might even fit workflows I haven't imagined yet.

I would be happy if ghfs helps you in ways I never expected.