--- title: "Kobako: Why Native Filesystem Support" date: 2026-10-21T00:00:00+08:00 publishDate: 2026-10-21T00:00:00+08:00 lastmod: 2026-10-19T20:33:04+08:00 tags: ["LLM","AI","Experience","Ruby","WebAssembly","Gem","mruby"] series: "kobako" toc: true aiTranslated: true permalink: "https://blog.aotoki.me/en/posts/2026/10/21/kobako-native-filesystem-support/" language: "en" --- Kobako recently moved to v0.28.0, which reworked the design that used to depend heavily on MessagePack. It's the first major revision since COSCUP wrapped up in August. Still, as we head into next year's (2027) AI applications, what capability is the Ruby ecosystem still missing? I think the answer comes back once again to the "Virtual Filesystem" [I talked about with friends at RubyKaigi in Japan this April](https://blog.aotoki.me/en/posts/2026/07/29/kobako-building-ai-era-sandbox/), so Kobako is about to support it as well. ## AI Native As I recall, people started proposing this idea last year, but calling a model was still expensive back then, and letting an Agent run on its own inside an environment was still hard. Over the past few months, though, with the price cuts on the GPT model family and Claude's Haiku 5.5 coming down to a level that can support large-scale use, AI Native has become much more feasible. Among all this, I think the Cloudflare ecosystem also makes it very practical. They released the [`@cloudflare/computer`](https://blog.cloudflare.com/cloudflare-computer/) package, which integrates deeply with the Cloudflare Workers ecosystem and lets AI have a Workspace of its own where it can edit and modify files. This matters a lot for AI Native. Until now, most AI use cases have happened on a personal computer: if I step away from my desk or don't turn the computer on, the AI can't work. But once we have a cloud environment, like the virtual machine behind Claude Cowork, a lot of things become possible. That way, we can hand a task to an Agent while we sleep, have dinner with friends, or at any other time, and it acts proactively. When an event happens (for example, an email arrives, a scheduled time is reached), it finishes the work on its own and waits for a human to confirm or review. This is the core idea of AI Native: things aren't driven by humans, they happen on their own. ## On Demand{#on-demand} If we want to give an Agent an environment to run autonomously, we can roughly choose between running the Agent itself inside an isolated environment, or giving the Agent tools and running those tools in an isolated environment. Claude Cowork falls into the first category, so it can run in the cloud quite easily. Claude Code is closer to the second: only command execution happens inside an isolated environment, which limits the blast radius. Both approaches have pros and cons depending on the situation. Cloudflare makes good use of Workers being built on V8 Isolates, running JavaScript code in a natively isolated environment. It then uses a virtual Shell emulated in JavaScript as the `Bash` tool, offering the way of working most Agents are already familiar with. When a filesystem is needed, it goes a step further and emulates a virtual filesystem on top of Durable Object's SQLite. For the Agent, it's not much different from working in a near-real environment. Cloudflare can go even further, though. When a real development environment is needed, it can start a container with the Container service, letting the Agent move from the emulated environment to a more realistic one. In most use cases, we can pick features at different price points as needed (Containers are billed by running time, which costs more than Durable Objects). Since Kobako was inspired by Cloudflare Workers, it's in the same position when it comes to a virtual filesystem. Earlier versions already used Kobako's Binding mechanism to provide an emulated one, so as a sandbox for AI Native it at least passes the bar. ## Possibilities{#possibility} If Kobako can already provide a virtual filesystem, why does it still need native support? The point is to open up more possibilities and to offer the right capability for each situation. Kobako's Binding goes through MessagePack encoding, so it gets much slower once the content reaches 64 KiB. This is almost unavoidable, because Binding was never designed to transfer large amounts of data in one go. But it also limits Kobako's ability to handle files, and when a Ruby application needs to pass larger data, it becomes a problem that narrows the use cases. A native filesystem doesn't have this limitation. Say we need to check whether a file exists: going through the Binding path, where MessagePack handles the call, takes around 2 microseconds, while the native path takes only 0.2 microseconds — at least ten times faster. On the other hand, if we want to process a larger file, the Ruby side can store it in a directory and the Guest can read and process it directly. Letting an Agent write an on-demand CSV processing tool becomes easy, and the Agent can download and process files as a stream. Many situations that used to be heavily restricted are now unblocked. Beyond that, a filesystem usually carries another layer of meaning in UNIX operating systems: network transfer is implemented through a similar low-level abstraction. This means that in the future we might even access the network directly from Kobako and run a real Agent that is fully isolated, which could open the door to even more use cases. Kobako keeps evolving around its original question, "What does Ruby still need in the AI era?" Although the scope I have to maintain myself has grown a bit larger, being able to give the Ruby ecosystem more options is still something to look forward to.