redbook signs requests with your Xiaohongshu session, and ships the signer as an export

It drives a third-party platform with your session, so keep it on your own account

The first thing to establish is scope, because this tool automates a service you do not control using credentials that are yours. It authenticates with your browser cookie rather than an API key, and it can read, search, analyse, comment, reply in bulk, bookmark, and publish. That is a legitimate tool for your own account and your own content, and it is also the kind of tool that misbehaves badly when pointed at someone else's. The platform's own risk controls are part of the environment: the project notes that it detects automated behaviour with uniform timing, and it says outright that publishing is easily stopped by a captcha. The right posture is a research and drafting tool on an account you would be content to lose, not a growth automation. Nothing here should be pointed at accounts you do not own, at bulk reply lists you did not build, or at a scale where the only thing separating you from a ban is the tool's own caution.

The request signer is a published export rather than an internal detail

The package manifest is candid about what it is. The description reads as a command line tool for the platform, and the summary line says it reads and posts through a private API. Then the exports field, which is the interesting part. The package publishes four entry points: the main client, a cookies module, a signing module, and a render module. Publishing the signer means the code that authenticates a request against the platform is a supported import for other software rather than something buried inside a command. That is a deliberate choice, and it cuts both ways. It is what makes the tool extensible and what lets a developer inspect how a signature is produced rather than trusting a binary. It is also the piece whose continued existence depends on a platform changing its private scheme, so a consumer who depends on that export directly is coupled to the same thing the CLI is.

The write path does not work and the documentation says so

The publishing command is documented with a warning attached to it. The note says the feature is prone to triggering a captcha, identifies the specific error code, says image upload works correctly, says the publish step itself is frequently intercepted, and then recommends using browser automation instead if you need to publish. That is an unusual thing for a tool to say about its own headline capability, and it tells you where the project is. Everything on the read side is a working surface: search with sort and content-type filters, reading a note, pulling comments, browsing the recommendation feed, resolving a profile, listing a profile's posts, searching topics, and reading saved albums. The analysis commands sit on that read side too, including one that examines whether a note has been silently throttled by reading a hidden field in the creator-facing interface, and one that extracts a content template from one to three high-performing notes.

The Windows path works around App-Bound Encryption by using Chrome

The authentication problem on Windows is real and the documentation treats it as a fact of life rather than a bug. Chrome 127 and later use App-Bound Encryption, so a separate process cannot read cookie values out of the browser profile the way it used to. The tool's answer is to close Chrome and let the command start Chrome in headless mode, so that Chrome itself decrypts the values and hands them over. The error code for the failure case is named, and the fallback is to copy the two relevant cookie values by hand out of the browser's developer tools, with the menu path spelled out. On macOS the equivalent friction is a keychain prompt, and the instruction is to choose always allow, which grants persistent access. Both are reasonable workarounds and both are worth pausing on, because each one is a deliberate decision to give up a browser security boundary in exchange for a session you can use from a terminal.

Five cookie sources, and a plaintext file on disk at the end of the chain

The cookie resolution is a five-step fallback chain and the order tells you what the tool considers most convenient. A cookie string passed on the command line wins, then an environment variable holding a string, then an environment variable pointing at a file, then a default file in the user's home directory, and only then does it reach into the local browser. So the path of least resistance for a cloud server or a CI runner is a cookie file, and the file is a plaintext login credential. The documentation is straight about the consequences: the file is written with owner-only permissions, it should not be committed, it should not be pasted into logs, and to revoke it you delete the file or run the clear command and then sign out and back in to refresh the session. Three sub-commands exist for managing it, and two of them are the ones worth knowing about, one that reports where the file is and which key names it holds, and one that inspects it, both of which are described as not printing cookie values.

Batch reply adds random jitter so the traffic does not look automated

One command deserves to be named plainly rather than buried. Batch reply posts comments on a note according to a strategy, with a template that can address the author and quote their content, a cap on how many replies go out, a configurable delay, and a preview mode. The delay is not a fixed interval: the documentation states that the tool adds random jitter to the reply interval specifically because the platform detects automation by uniform timing, and it recommends limiting bulk replies to one or two passes per note per day. That is a design decision to make traffic look less like a script, and it is worth evaluating on those terms. It also means the command's defaults are tuned for evading a detection signal rather than for finishing a job, and the author has flagged the platform's own view of that behaviour. Everything else the tool does, it could do with a session; this one is explicitly built to look human to the platform, and that is a different category of decision for whoever installs it.

The package ships install and uninstall hooks

The manifest declares three lifecycle scripts and ships the directory they live in. The build step compiles the TypeScript and marks the entry file executable, the prepublish hook runs the build, and there is both a postinstall and a preuninstall script, each a small Node program in the scripts directory, and the publish file list includes that directory so they are present in the installed package. Hooks that run on install and on uninstall are ordinary in packages that generate something or clean up state, and here the cleanup is presumably about the cookie material, which makes the uninstall hook the piece to read before installing. A related detail is the optional dependency structure: the browser renderer and the Markdown parser are declared as peer dependencies marked optional, so a plain install does not pull them and the render command needs two packages the user installs separately. They are also the only heavyweight pieces, and the renderer uses the browser you already have rather than downloading one.

The documented first step is a prompt you paste into an assistant

The onboarding section is written for an agent rather than for a person. It presents a block of text to hand to an assistant, with the install command and a verification command inside it, plus a repository link, and notes that users of a particular agent ecosystem can install through that ecosystem's own package command instead. The commands are short:

npm install -g @lucasygu/redbook
# or install through the agent ecosystem's own registry
clawhub install redbook

Node 22 or newer is required, and macOS, Windows and Linux are all supported. The keywords in the manifest reinforce the positioning, listing both a coding agent and a skill marker alongside the platform names. The repository carries a skill definition file at the root and that same file is listed in the published files, so the skill ships with the package rather than being fetched separately. The reasoning is not unreasonable for a tool whose workflows are multi-step analysis chains rather than single commands. It does mean the first thing a new user is asked to do is delegate their authentication to something they have not yet read, which is a reasonable trade for a research tool and a poor habit for anything with write access.

Editorial conclusion

Use redbook on an account you own, for reading and for your own content, and think hard before you let it write. The read side is the mature half: searches, profiles, comments, feeds, saved collections and the analysis commands all go through the same private API, and the one command the project admits does not work reliably is the one that publishes. The second thing to weigh is the credential model. Authentication is your live browser session, extracted from Chrome, Safari or Firefox, optionally copied by hand out of developer tools, and optionally written to a plaintext file. The documented way past Chrome's App-Bound Encryption on Windows is to close Chrome and let the tool launch it headless so that Chrome itself performs the decryption, which is a real trade against a security feature added for exactly this reason. Two implementation details deserve a look before you install. The package exports its cookie and signing modules as public entry points rather than keeping them internal, which makes the request signing reusable by other code, and it ships install and uninstall hooks. The last commit on the default branch main is dated 12 September 2026, which is also the date of the newest release.

Frequently asked questions

Official sources

1. License: MIT
2. lucasygu/redbook on GitHub
3. Project website
4. README
5. Releases