{/* banner prompt: A playful and polished 3D diorama of a cozy workspace, a cute Linux penguin mascot carefully organizes files within a single, solid terracotta-colored folder on a desk, while a vast, abstract library of semi-transparent files gently swirls in the background, rendered with soft lighting and matte materials, distinctive color palette of sage green, terracotta, and cream, 16:9. */}

There is a particular kind of cloud-storage problem that only appears after you have accumulated years of useful files: you rarely need the whole drive, but you still want the part you are working on to feel local.

For me, that might be a tax folder for one financial year. I want to open it in ordinary Linux tools, add receipts, edit spreadsheets, run scripts, and eventually send the finished folder back to Google Drive. I do not want a background mirror trying to make two entire trees identical while I am still deciding what belongs in the project.

That is why we built [TYO CloudDrive](https://github.com/tyolab/tyo-clouddrive), an open-source Google Drive client for Linux. The command is `tyocd`, and its design is deliberately conservative: browse Drive lazily, check out only the folder you need, and make uploads an explicit, reviewable operation.

## Three ways to work with Drive

TYO CloudDrive has three separate modes because browsing, editing, and one-off transfers have different safety requirements.

<Table data={
    {
        headers: ['Mode', 'Best for', 'What it does'],
        rows: [
            ['Lazy virtual drive', 'Browsing a large Drive', 'Shows folders and fetches file content when opened'],
            ['Editable workspace', 'Working on one project or year', 'Checks out one Drive folder into a local directory'],
            ['Additive transfer', 'Sending a separate local tree', 'Creates new Drive objects from an immutable plan'],
        ]
    }
} />

The important word is **separate**. TYO CloudDrive is not a background mirror-sync engine. It does not watch your local filesystem and silently propagate every rename or deletion. That makes it a little less magical, but much easier to reason about when the files matter.

## Browse without downloading the whole drive

The read-only FUSE mount gives Linux a familiar directory view of Google Drive:

```sh
mkdir -p ~/TYOCloudDrive
tyocd mount ~/TYOCloudDrive
```

Folder metadata is loaded when a directory is listed. A binary file is downloaded only when something opens it, then stored in a private cache and checked against Drive's size and MD5 checksum when available. If Drive's version has not changed, the cached bytes can be reused.

The mount is read-only at several layers. It does not write through changes, rename Drive objects, or delete anything. Google Docs, Sheets, and Slides appear as small link files such as `.gdoc`, `.gsheet`, and `.gslides`, which is more useful than pretending an exported copy is the original document.

There is one honest limitation: opening a binary file currently downloads that file in full. Sparse range caching is not implemented yet. The lazy part is selecting which files to fetch, not fetching only the first few kilobytes of a large file.

## Check out one folder as a local workspace

When I am doing real work, the editable workspace is the more interesting feature. Give it a Drive folder ID and a local destination:

```sh
tyocd workspace checkout DRIVE_FOLDER_ID /home/me/Documents/Tax
```

The checkout copies only the selected subtree. TYO CloudDrive keeps an exact-ID manifest in private application state rather than adding metadata files to the project directory. That manifest records the Drive IDs, local checksums, remote versions, and folder relationships needed to tell a genuine change from a confusing filename coincidence.

The normal loop is:

```sh
tyocd workspace status /home/me/Documents/Tax
tyocd workspace plan /home/me/Documents/Tax --path 2026 --update
tyocd --yes workspace apply PLAN_ID
```

The plan is a saved JSON document identified by a SHA-256 digest. Before the first write, apply checks the local files, the exact Drive objects, their versions, and the relevant parent folders. If the cloud copy changed while you were working, the plan becomes a conflict instead of guessing which copy should win.

That is useful for a year-by-year folder. You can prepare `2027` locally, add only the receipts and working files that belong there, inspect the plan, and then upload that scoped subtree. A new local folder can be created in Drive without pulling unrelated changes from `2025` or the rest of the account.

## Safety rules that shape the product

The safety model is not a warning printed above an unsafe operation. It is part of the command structure.

- There is no permanent-delete command and no mirror-delete algorithm.
- A remote-only item becomes `keep_remote`; it is never treated as permission to delete a local copy or vice versa.
- A changed bound file is a conflict unless `--update` is explicitly supplied.
- Every upload is snapshotted and checksum-verified before mutation.
- Creates use pre-generated Drive IDs, so an interrupted apply can be replayed without making duplicate objects.
- File replacements retain the current binary revision before the conditional update.
- Updates use an HTTP `If-Match` check so a last-second remote change stops the write.
- A local deletion does not delete the Drive object.

The last rule is especially intentional. A local workspace is a place to work, not a mirror with authority to erase the source of truth.

## Open source, and still early

TYO CloudDrive is MIT licensed and available at [github.com/tyolab/tyo-clouddrive](https://github.com/tyolab/tyo-clouddrive). It is written in Go and targets Linux. The ordinary CLI and workspace commands do not require FUSE; the optional mount does.

To build it:

```sh
git clone https://github.com/tyolab/tyo-clouddrive.git
cd tyo-clouddrive
make build
./bin/tyocd --version
```

You bring your own Google OAuth desktop client, authorize the scope you need, and then choose whether to browse read-only or use the write-capable workspace flow. The full [usage guide](https://github.com/tyolab/tyo-clouddrive/blob/main/docs/USAGE.md) explains the commands and the recovery behavior.

This is early alpha software. The core safety model is implemented and tested, but it is still wise to start with a disposable Drive folder and keep an independent backup. Retained Drive revisions and the trash are recovery layers, not a backup strategy.

The goal is modest: make Google Drive feel useful on Linux without making local work feel like a high-stakes synchronization experiment. If you want a whole-account mirror, this is probably not the tool. If you want a small, deliberate part of Drive to behave like a project, that is exactly what we are building.


eb78adb9267b40fdda634acc0fc9773e9b186877b0c71ad3622d8d9c0eb4da0d

TYO CloudDrive is an open-source Linux Google Drive client with a read-only lazy mount and safety-first selective folder checkouts.

Introducing TYO CloudDrive, our open-source Linux CLI for safer Google Drive browsing, lazy virtual mounts, and selective editable folder workspaces.

Tag: Tyo Clouddrive

Tag: Tyo Clouddrive

TYO CloudDrive: An Open Source Google Drive Alternative for Linux