BaiduPCS-Go (qjfoidnh fork): a Baidu Netdisk CLI with transfer support

What qjfoidnh/BaiduPCS-Go actually adds to the original client

The upstream iikira/BaiduPCS-Go stopped at v3.6.2. This fork picks up from there and, per the README, adds transfer support: the ability to save another user's shared files into your own netdisk, including links that carry a password. That is the feature the project leads with, and it is the reason the fork exists rather than being a cosmetic repackaging.

The rest of the tool is what the original was: a Baidu Netdisk client that mimics Linux shell file commands. It handles login, listing, searching, downloading, uploading, copying, moving, deleting, sharing, offline downloads and the recycle bin. It is aimed at people who already think in terms of ls, cd and cp, and who would rather script netdisk operations than click through a web page.

One point in the README deserves attention because it sets expectations: the software does not provide download acceleration beyond what the official client gives. Configuration suggestions for regular and SVIP accounts are documented under the config section, but the project does not claim to bypass rate limits.

How the client is structured and where transfer fits

The repository layout reflects a Go CLI with a layered internal design. main.go sits at the top, cmd/ holds the command definitions, baidupcs/ is the netdisk API layer, and internal/, pcsliner/, pcstable/, pcsutil/, pcsverbose/ and requester/ hold supporting code. The go.mod file pins the toolchain at Go 1.23 and pulls in urfave/cli for command parsing, peterh/liner for the interactive shell, and two project-owned dependencies, qjfoidnh/Baidu-Login and qjfoidnh/baidu-tools.

The transfer command is the differentiating path. It takes a share link (with or without a password) and writes the shared content into the logged-in account. The v4.0.2 release notes add a --fs_id flag to the transfer command for granular file selection, and note that transfer now supports share codes (分享口令). Rapid-upload transfer (秒传转存) has a separate history: it was disabled in v3.9.6, restored in v3.9.5 with a required accessToken set through setastoken, and the changelog records repeated breakage and repair as Baidu changed interfaces.

That history is the most useful thing to understand about this project. The commands are stable in shape; the endpoints behind them are not.

Installing BaiduPCS-Go and transferring a share link

The README does not give a package manager install. It says compiled binaries for common platforms are downloadable from a Lanzou Cloud link (password 4pix), and that the program is written in Go, so you can build it yourself. To build from source, set GOOS and GOARCH and run go build; the README gives this Linux/Darwin example for producing a 64-bit Windows binary:

GOOS=windows GOARCH=amd64 CGO_ENABLED=0 go build

On Windows the README recommends Command Prompt or PowerShell rather than mintty, since GitBash can produce display problems. On Linux and macOS it expects a terminal. If output looks garbled, the README says to check that the terminal encoding is UTF-8.

Running the binary with no arguments drops you into an interactive shell whose prompt reads BaiduPCS-Go >, or BaiduPCS-Go:<working dir> <account>$ once logged in. Login is required before any netdisk operation, and the README lists it as step 2 of the beginner tutorial. The command list is long enough that the fastest start is to check the help output for the subcommand you need before running it.

The first real use is a transfer. The README documents a transfer command for saving other users' shared files, with support for password-protected links, and v4.0.2 added --fs_id for selecting individual files inside a share. Because the README does not reproduce the full flag syntax in the excerpt available here, check transfer --help in your installed build rather than copying a flag from a blog post; the flags have changed across releases.

Known limits: uploads, API drift and the acceleration question

The v4.0.0 release notes state that upload no longer supports resumable transfer because of an interface change, while download is unaffected. That is a real operational constraint: a large upload interrupted partway has to start over at the file level, not resume mid-file. The same release added a --policy flag accepting skip, overwrite and rsync for same-name files, plus a config default, which softens the pain but does not remove it.

API drift is the second limit. The changelog is a record of features being removed and restored as Baidu changes its side: rapid-upload transfer was cancelled in v3.9.3 because the official interface blocked it at the principle level, then restored in v3.9.5 with an accessToken requirement. Any workflow that depends on rapid upload or rapid transfer should be treated as fragile.

The third limit is scope. This is not a download accelerator. The README states the software does not offer speed beyond the official client, and the v3.8.6 notes recommend keeping download thread count at or below 12. If your goal is faster downloads, this tool is the wrong choice.

How it differs from the original iikira client and from a web front end

The direct alternative is upstream iikira/BaiduPCS-Go v3.6.2. The difference is not stylistic: upstream stopped there, and this fork continues development on top of it, with transfer support as the headline addition. If you only need listing, download and upload against Baidu Netdisk and you are content with the older code, upstream is the smaller surface. If you need to save other people's share links into your own account from a script, upstream does not do it.

A second alternative is a browser-based front end for Baidu Netdisk. Those put a graphical interface over the same account and are easier for occasional use, but they are not scriptable in the way a shell client is, and they do not give you the same command vocabulary for bulk operations. The trade-off here is deliberate: this project asks you to learn its command set in exchange for automation.

Maintenance, licensing and the cost of keeping it working

The repository is not archived, and the last push was on 2026-09-09. The most recent release is v4.0.2 on 2026-08-21, preceded by v4.0.1 on 2026-03-26 and v4.0.0 on 2025-10-28. The cadence is irregular, which fits a project whose releases are often responses to upstream interface changes rather than a planned roadmap.

Upgrade cost is the practical concern. Because Baidu's endpoints move, an old binary can stop working even if you change nothing. The project ships an update command, and v3.7.2 notes that online upgrade was restored and uses a mirror source for speed. Budget for periodically rebuilding or re-downloading rather than assuming a pinned binary stays functional.

The licence is Apache-2.0, stated in the repository. That is a permissive licence, and it matters here because the project is a fork of a fork: iikira/BaiduPCS-Go was itself inspired by GangZhuo/BaiduPCS. If you redistribute a modified build, read the LICENSE file in the repository for the attribution and notice requirements rather than relying on a summary.

Editorial conclusion

Adopt it if you already treat Baidu Netdisk as a storage backend and want scriptable upload, download and transfer commands on Linux or macOS. Skip it if you need a graphical interface, guaranteed download acceleration, or a tool that keeps working without occasional breakage when Baidu changes its endpoints; the changelog shows repeated fixes for that reason. Before committing, verify that login succeeds with your account type, that uploads work from your network (an overseas VPS may need the proxy_hostnames config described in v4.0.0), and that the transfer command handles the share link you actually use, including password-protected ones.

Frequently asked questions

Official sources

1. Issues
2. License: Apache-2.0
3. qjfoidnh/BaiduPCS-Go on GitHub
4. README
5. Releases