rednote-gate

rednote-gate

中文说明

rednote-gate drives ONE dedicated throwaway RedNote (Xiaohongshu) account. Never point it at a primary or brand account. It works by browser automation, which is against RedNote's terms of service. The account can be rate limited or banned. Only use an account you can afford to lose.

Website: https://yashshelar007.github.io/rednote-gate/

It is a local MCP server for Claude Code, Claude Desktop and Codex. Reads run directly. Every write waits in a queue until a human clicks Approve on a local web page.

Quick start

Install from npm

npm install -g rednote-gate

rednote-gate setup

That installs Chromium, opens the QR login for your throwaway account, and connects rednote-gate to Claude Code. Your data and login live in ~/.rednote-gate.

Or from a clone

git clone https://github.com/YashShelar007/rednote-gate.git

cd rednote-gate npm run setup

Same steps, plus the build. A clone that already has a login in .session/ keeps its data in the clone folder.

Then use rednote-gate's prompts. Claude Code shows them as slash commands:

Or just ask in plain words ("post these two photos about my hike"). The first time you use a rednote tool, a small background service starts. It owns the browser, the approval page and the worker, and it keeps running after you close Claude Code, so the approval page always works and approved items always run. It closes the browser window after 5 idle minutes. Stop it with rednote-gate stop (npm run stop in a clone). When something is queued, the approval page opens in your browser and your Mac shows a notification. You click Approve. About 30 seconds later it runs, and the page shows a screenshot of the result. You get a notification when it is done, or if RedNote ever shows a captcha.

Status: every flow was checked against the live site on 2026-10-06 on a rednote.com account, headed: four reads, and one real publish, draft, comment and reply, each approved by a human on the approval page. See Last verified against the live site.

How it fits together

The model calls tools. You choose prompts. The background service, the approval page and the rednote-gate CLI are not part of MCP. The approval page is a local web page on 127.0.0.1. It sits outside MCP on purpose, so the model cannot approve its own writes.

What it does

rednote-gate is a local stdio MCP server. It needs Node 20 or newer. It is written in TypeScript and drives Playwright Chromium on your own machine.

Read tools run straight away:

Write tools only add an item to the queue and return its queue id. They never touch the browser.

For rednote_reply_comment, pass the id, author and text exactly as rednote_get_comments returned them. Before replying, the worker reads the comment with that id from the page and checks that its author and text still match exactly. If not, it does not reply.

Titles, comments and replies must be a single line: a line break would be typed as Enter, which can send a comment early. The body of a note may have line breaks.

Note URLs must look like https://www.xiaohongshu.com/explore/ ?xsec_token=... (or www.rednote.com for overseas accounts). Take them from rednote_search results. Bare URLs without the token are refused, because RedNote answers them with a captcha. See docs/friction.md.

How the approval gate works

A short example:

1. You ask Claude: "Post a note about my desk setup with /Users/me/pics/desk.jpg."
2. Claude calls rednote_create_post. The server checks the image, copies it into the queue and hashes it. It returns a queue id such as q_20261006T153012_ab12. No browser opens. Nothing is posted.
3. You run rednote-gate approve and open the link it prints. The page shows the exact title, body and image. You click Approve.
4. The worker checks the queue every 10 seconds. It waits 30 seconds after your click, so you can still press Cancel, then picks up the item if the budget allows. It writes an attempt line to the ledger, then opens the creator page, uploads the image and types the text.
5. In dry run mode (the default) it stops before the final click. The item becomes dry_run. In live mode (rednote-gate live) it clicks publish. The item becomes posted.
6. Claude can call rednote_queue_status to see the result. It never gets the approval link.

Clicking Approve only marks the item. It does not post anything by itself. There is no approval in chat. Telling Claude "yes, post it" changes nothing.

Statuses

pending  -> approved | rejected

approved -> posting | rejected (Cancel) posting -> posted | dry_run | failed | unknown

Queuing an identical write returns the existing id instead of a second item. Identical means same tool, same arguments and same image bytes. This applies while the first one is pending, approved, posting, posted or unknown.

Guardrails

• Approval in code. Write tools only queue. The worker clicks the final button only in live mode, and only on an approved item.
• What you approve is what posts. Images are copied into the queue and hashed when queued. Only real JPEG, PNG or WebP files pass, checked by file signature. Each image can be at most 20 MB. A note takes 1 to 9 images. That is a project limit, not RedNote's.
• Daily budget. At most RN_DAILY_WRITES live attempts (default 5) in any rolling 24 hours. Comments and replies also need RN_COMMENT_GAP_MIN minutes (default 10) since the last live comment or reply attempt. The budget is worked out from the ledger, so a restart does not reset it. Failed and unknown live attempts count. Dry runs do not. An approved item over budget waits. The approval page shows when the next slot opens.
• Undo window. The worker waits 30 seconds after Approve. Until then, Cancel stops it.
• An approval is tied to its mode. "Approve dry run" only ever runs as a dry run. If you restart in live mode, earlier dry-run approvals do not run; the page tells you to cancel and approve again.
• Read back before sending. After typing, every field is read back. If a topic or mention picker, or anything else, changed the text, it stops before the final click.
• Crash safety. The attempt line is written before the browser starts, so a crash still uses up budget. A live item cut off mid attempt becomes unknown and is never retried. A dry run cut o