mizorewww/gdirect

Worth trying if you already live in a terminal and need large Drive transfers to behave better on a constrained network. gdirect wraps Google Drive in a TUI, CLI and FUSE mount, and its defining step is a local scan of Google IPs instead of using whatever route your system normally takes.

The problem

A common workflow is: find a large file in Drive, download it, and then recover from a dropped connection by restarting or manually resuming. In a terminal, listing and downloading normally means juggling a browser or separate API scripts, and a flaky route makes a big file painful. gdirect changes the middle of that workflow: browse opens a file browser in the terminal, d queues a download, and the transfer runs over a Google IP the tool has scanned and kept for 24 hours. Afterward, files are checked against Drive's MD5 and finished downloads are recognised by checksum.

What's different

The mechanism is a scan for reachable Google IPs, after which Drive API, download and upload traffic go straight to the selected IP while sign-in and token refresh still use the normal system network. The practical benefit is that transfers can use multiple connections (up to 16) and resume from a partial file when the same command is re-run, without you crafting the resume yourself. mount takes a separate path through rclone and also uses the normal system network. The trade-off is a network setup you must maintain: with a TUN-mode proxy or VPN, the scanned IPs need a DIRECT route and fake-ip disabled, or the scan finds nothing. The README also notes that changing the TLS SNI does not bypass certificate checking, so the SNI options are not a generic way around network policy.

Who should try it

Good fit: a developer or power user who wants terminal-driven Google Drive access, large downloads with resumable multi-connection transfers, or a mounted Drive, and who can adjust proxy rules. Poor fit: someone who wants a one-command sign-in without creating a Google Cloud OAuth client, or who needs a shared client out of the box; gdirect deliberately does not ship one. Also a poor fit for anyone unwilling to do the roughly 10-minute one-time Google setup, or whose environment cannot install the mount dependencies. If you only need Drive inside a desktop file manager, this project's terminal and mount workflow adds steps rather than removing them.

Requirements and limitations

Platform coverage is specific: prebuilt binaries target macOS 15+ (Apple Silicon and Intel), Linux x86_64 with glibc 2.35+, and Windows x86_64; Alpine/musl, older glibc and Linux ARM64 require a source build with Rust 1.91+, a C++ compiler, OpenSSL 3 and other build tools. Sign-in and token refresh must reach Google through your system network, so a blocked Google still needs a proxy or VPN for that step. Mounting adds rclone 1.75.2+ and, on Linux, FUSE3; Windows needs WinFsp, which may require administrator approval. Expect ongoing maintenance rather than a one-time install: proxy rules for the scanned IPs, the documented 7-day sign-in expiry, and the mount's upload cache, which tries to stay under 5 GiB but can exceed that with open or unsent files. The README says unmount keeps unsent files and the next mount uploads them, but the core transfer tool remains a separate moving part from the mount.

HotRepo's take

The only HotRepo observation is a NEW-REPOSITORY board placement at #14 with 367 total stars on 2026-10-25, not an overall Trending rank and not a daily growth figure. With a single recorded date and an age of 0 days, persistence cannot be judged from the trend data. Before adopting, verify the Google OAuth setup guide and the troubleshooting notes against your proxy and platform, since those are where the friction is likely to surface.