TiDB Cloud FilesystemThe workspace your agents share
One filesystem, held by several runtimes at once, that knows what an agent leaves behind — dirty tree, new objects, test output, artifacts.
What makes it different
Three things TiDB Cloud Filesystem does that your sandbox disk can't
All three exist for one reason: a distributed database sits under this filesystem, so it can promise things a disk can't.
Git-aware workspace
A resumed workspace still has its git state
The branch, the uncommitted changes, the objects the agent created — all of it comes back on resume. Not a fresh clone; the actual working state.
WHAT COMES BACK, IN ORDER
01clean tree
the committed baseline
02dirty overlay
uncommitted modifications
03object pack
objects the agent created
ti fs-git clone-git-workspace · hydrate-git-workspace · add-git-worktree
Rebuildable vs persistent
Keep what your agent needs. Drop the noise
node_modules and dist can be rebuilt anywhere, so they stay local. What can't be rebuilt — test results, failure logs, patches — is what persists.
THE SPLIT, FILE BY FILE
PERSISTED
sourcelock filepatchestest resultsfailure logsLOCAL-ONLY
node_modules.tsbuildinfodist.turbocoverageThe split follows the project's own shape, not a config file you maintain.
Any file, any format
One place for everything the agent touches
An agent's working set is never just code — it's source, uploads, datasets, test output, artifacts. One durable workspace holds all of it, instead of a repo plus a bucket plus a log shipper.
THE WORKING SET, IN ONE PLACE
The same path from CLI, IDE, agent and CI — one namespace.
Proof at scale
Agent workspace continuity, running in production
0+
file systems in production behind Kimi Work (Moonshot AI)
TiDB Cloud Filesystem holds the agent workspaces behind Kimi Work, Moonshot AI's desktop AI agent for knowledge workers — which is why the runtimes that execute those agents stay disposable.
How it works
Execution is disposable. State is not
Two planes, one namespace. Runtimes come and go above; the workspace below is addressed as a service and outlives all of them.
One coding agent task, eight steps — each leaves state the next one needs
A coding agent doesn't touch a filesystem once. It touches it at every step, and the loop ends where a sandbox volume can't follow.
Enter the repository
Tree and metadata arrive first; content loads on access.
metadata-first · lazy hydration
Search
Content grep and filename find, with build noise kept out.
fs search-file-content · fs find-files · ignore policy
Read context
Handler, config, test and failing log arrive as one batch.
inline small files · batch read
Edit files
Writes land locally first; a journal keeps them recoverable.
local-first write · journal · async writeback
Build and test
Rebuildables stay local. Results, logs and patches persist.
build profile · local-only overlay
Save Git state
Baseline, dirty overlay and new objects — modelled separately.
ti fs-git · clean tree · dirty overlay · object pack
Checkpoint
Layer commands are in the CLI — not yet a preview guarantee.
fs create-layer · create-layer-checkpoint · rollback-layer — preview, not guaranteed
Hand off
The next runtime opens the same workspace. Same token, no mount required.
filesystem token · one namespace · fs read-file, mountless
Where it fits
Start with the boundary your state has to cross
You're in the right place if —
A sandbox or ephemeral job ends before the task is done.
Each run clones and prepares the same repository again.
Several agents need the same repository or document set at once.
Work moves between E2B, Modal, Daytona, CI or a local tool.
Several kinds of storage persist real work.
Which one is right depends on what has to survive, and what it has to cross.
WHAT YOU NEED TO KEEP
USE
A durable disk attached to one workload
Block storage
A shared POSIX filesystem for compute clients in one cloud
Network file storage
Objects, artifacts, datasets, backups or archives
Object storage
Analytics over large tables, or an AI data workflow
Committed source history, branches and merges
Git hosting
What an agent remembers across conversations
Agent memory
Snapshots and forks of work inside one sandbox platform
Platform-native persistence
One active working directory crossing runtime, session, agent or reviewer boundaries
TiDB Cloud Filesystem
Hands-on lab
Try it in a real sandbox
A guided, 120-minute lab using a virtual machine.
Straight answers
What TiDB Cloud Filesystem is, and what it isn't yet
Get started
Nothing to rebuild. Everything to build on
Write from one runtime. Let it end. Reopen the workspace from another and check that the second run continues from the first. That's the whole test.