A small tool that securely syncs logged-in Zhihu and Weibo sessions from Microsoft Edge to your self-hosted RSSHub — without modifying RSSHub source or depending on CookieCloud — and handles verification, switching, rollback, and alerts.
Once you self-host RSSHub, there's one class of problems you can't really avoid: some routes need a logged-in session to work, like Zhihu or Weibo.
But cookies expire on their own schedule, with no heads-up. By the time you notice a cookie has expired, your feed has been sitting stale for a long while. Then it's back to digging through the docs, fishing a cookie out of the browser, logging into the server, editing the Compose file, and rebuilding the container. None of it is hard, but it adds up to a lot of wasted time.
What makes it worse is that "no new posts for a while" doesn't actually prove the cookie is dead. The author may simply not have published, and the upstream could be rate-limiting or having a brief outage. If you judge purely by whether the feed updates, it's all too easy to swap in a new cookie when you shouldn't touch a thing.
To solve this, I wrote RSSHub Cookie Sync. It pushes the logged-in Zhihu and Weibo cookies from Microsoft Edge to your own RSSHub server, validates the candidate sessions first, and only switches over when there's a real need. If a fresh login is unavoidable, it pings you through Bark. None of this touches RSSHub's source, and it doesn't depend on CookieCloud.
What it solves isn't "copying a cookie" but the maintenance that comes afterward
Copying a cookie once is easy. The genuinely tedious part is the whole chain of decisions you have to make over the long run:
Is there a usable new session in the browser?
Is the cookie the server is actually using really dead?
Is the failure at hand an authentication problem, or rate-limiting, a timeout, or an upstream outage?
Is RSSHub still healthy after the swap?
If the switch fails, can we automatically fall back to the previous state?
When should it quietly retry, and when should it bring you back to log in?
So this project doesn't just overwrite RSSHub with whatever the browser has. Instead it treats the new cookie as a "candidate": the server validates the candidate and independently watches the live cookie. Only when both the validation and the switching conditions are met does the candidate get promoted; otherwise the existing live value stays.
A four-stage pipeline
Edge extensionhandles the part closest to the browser. It's built on Manifest V3 and requests only the permissions it needs for cookies, scheduled tasks, Native Messaging, and local state. The Zhihu and Weibo host permissions are optional and must be granted by you on purpose. Auto-sync fires on Edge startup, every 15 minutes, and whenever a target cookie changes — and after a cookie change it first merges for a short window so it doesn't upload in a flurry.
Native Hostis the bridge between the browser extension and your machine's system capabilities. The extension never touches your SSH private key, and no server connection details are baked into the extension package. The Host only accepts a constrained server address, port, and a single-level key filename under ~/.ssh/, and then calls the system's OpenSSH.
The restricted SSH accountis fixed as rsshub-sync. It has no ordinary shell and isn't in the Docker group; on the server side a forced command confines it to the sync protocol. Cookies travel over SSH's standard input, so they never appear in the command arguments.
The server makes every decision that can affect RSSHub: checking input, verifying the upstream, saving the candidate, updating the live env, inspecting the Compose file, rebuilding the target service, waiting for the health check, and rolling back on failure. A systemd timer keeps those checks running even when the Mac is asleep or Edge is closed.
Why it doesn't swap the cookie on the first failure
When it judges the session state, the project probes the Zhihu and Weibo login endpoints and the RSSHub health status directly, rather than watching for "new articles." The server classifies each result as an authentication failure, a transient fault, or a healthy state: a clear authentication failure is counted and confirmed cumulatively;403,429,432, timeouts, and 5xx are treated as transient upstream faults and don't trigger an immediate cookie rotation.
That distinction matters. Rotating cookies blindly during rate-limiting not only fails to fix anything, it can even replace a session that still works. Auto-repair is only meaningful when the live cookie has been confirmed dead and the server already holds a validated candidate. If there's no usable candidate, Bark tells me to go back to Edge and log in again, and persistent transient faults — plus the eventual recovery — are alerted according to policy.
Zhihu and Weibo are tracked independently. Trouble on one service never clears or blocks the other's valid session.
Treating failure as a normal branch when updating RSSHub
On first hookup, the installer migrates ZHIHU_COOKIES,WEIBO_COOKIES, and TWITTER_AUTH_TOKEN from the environment of the target RSSHub service in the Compose file to secrets/rsshub.env next to it, loading them with env_file's raw format. That way characters like $,# inside cookies are never re-interpreted by Compose, and the secret file is tightened down to root-only readability.
What happens afterward isn't "write a file and pray." The server holds a lock, runs the change as a transaction, writes the new env atomically, checks the Compose config first, rebuilds only the target RSSHub service, then polls the health check. If any step fails, it restores the old env and re-establishes the previous running state. It never runs docker compose down, never rebuilds Redis or browserless, never pulls images, and never deletes volumes.
This part deserves coverage more than "how to get a cookie": the most dangerous thing about automation usually isn't what it can't do, but the ambiguous in-between state it leaves behind when it only finishes halfway. Here, installation, migration, switching, and uninstallation all treat interrupted-recovery, boundary checking, and idempotency as the normal path.
Where the credentials live
A cookie is, at bottom, a login credential. The project keeps its exposure path as short as it can:
The extension filters cookies by the target request origin, and live values are never written to the extension's persisted state;
During transfer, cookies exist only fleetingly in the memory of a single call and SSH standard input — never in local command arguments, environment variables, or logs. Ultimately they land in the server's root-only env file and the container environment, exactly as RSSHub requires;
The Native Host returns only fixed, redacted status and never carries arbitrary server error text back into the extension;
On your machine, a dedicated project Ed25519 key is used by default, with no silent fallback to the generic id_ed25519;
SSH strict host key checking is on, so unknown hosts are never accepted automatically;
On the server, the live env, candidate, state, and Bark config are all restricted to root-readable.
These measures can't erase the trust boundary of the host machine itself. Anything running with your Mac's current-user privileges could still attack the browser or read the SSH files that user can read; and anyone with server root or Docker admin rights can read the cookies inside the RSSHub container. The project protects the sync path — it isn't a sandbox escape for an already-compromised OS.
Installation
A standard install is done across three ends. First, install the Native Host under your Mac's current user and copy the project public key the installer prints at the end:
Shell
curl -fsSL https://github.com/Jaaayden/rsshub-cookie-sync/releases/latest/download/install-macos.sh | sh
Next, connect to the server over ordinary SSH for the first time, verify and accept the host fingerprint. In the same root session run the server installer, choose your RSSHub Compose file when prompted, and paste in the public key you just copied:
Shell
curl -fsSL https://github.com/Jaaayden/rsshub-cookie-sync/releases/latest/download/install-server.sh | sh
Finally, grab the extension ZIP from GitHub Releases and install it at edge://extensions via "Load unpacked". Open the extension's connection settings, confirm the Native Host is reachable, fill in the server address and SSH port, pick the rsshub-cookie-sync dedicated key, authorize the Zhihu and Weibo site permissions, and run the first sync.
Warning
Please don't paste cookies, your Bark Device Key, your SSH private key, real server addresses, or unredacted Compose output into an Issue, a chat, or a screenshot. Releases also ship SHA256SUMS, so you can verify the downloaded file before a real install.
Scope and trade-offs
Right now the project targets macOS, the Microsoft Edge Chromium Default Profile, and a self-hosted RSSHub running Linux, systemd, Docker Engine, and Docker Compose v2.30+. The supported providers are Zhihu and Weibo; at runtime the server relies only on the Python 3.9+ standard library. Node.js is used only for testing the extension.
It won't type passwords for you, won't bypass CAPTCHAs or MFA, and can't magically stretch out a session that has already expired. When a human login is needed, the right move is still you going back to the browser and signing in. What this project does is judge clearly when it's time for you to come back, and reliably handle all the mechanical steps around it.
As of this writing, the latest version is v1.1.3. The repo contains the Edge extension, the macOS Native Host, the Linux server, install and uninstall scripts, plus automated tests covering protocol validation, key migration, transactional rollback, Compose migration, and monitoring policy.
Project home
Code, installation docs, troubleshooting, and the security policy all live on GitHub: Jaaayden/rsshub-cookie-sync. The project is MIT licensed. If you also self-host RSSHub and keep getting derailed by expired sessions, it might save you from a chunk of repetitive, error-prone maintenance.
Once you self-host RSSHub, there's one class of problems you can't really avoid: some routes need a logged-in session to work, like Zhihu or Weibo.
But cookies expire on their own schedule, with no heads-up. By the time you notice a cookie has expired, your feed has been sitting stale for a long while. Then it's back to digging through the docs, fishing a cookie out of the browser, logging into the server, editing the Compose file, and rebuilding the container. None of it is hard, but it adds up to a lot of wasted time.
What makes it worse is that "no new posts for a while" doesn't actually prove the cookie is dead. The author may simply not have published, and the upstream could be rate-limiting or having a brief outage. If you judge purely by whether the feed updates, it's all too easy to swap in a new cookie when you shouldn't touch a thing.
To solve this, I wrote RSSHub Cookie Sync. It pushes the logged-in Zhihu and Weibo cookies from Microsoft Edge to your own RSSHub server, validates the candidate sessions first, and only switches over when there's a real need. If a fresh login is unavoidable, it pings you through Bark. None of this touches RSSHub's source, and it doesn't depend on CookieCloud.
What it solves isn't "copying a cookie" but the maintenance that comes afterward
Copying a cookie once is easy. The genuinely tedious part is the whole chain of decisions you have to make over the long run:
So this project doesn't just overwrite RSSHub with whatever the browser has. Instead it treats the new cookie as a "candidate": the server validates the candidate and independently watches the live cookie. Only when both the validation and the switching conditions are met does the candidate get promoted; otherwise the existing live value stays.
A four-stage pipeline
Edge extensionhandles the part closest to the browser. It's built on Manifest V3 and requests only the permissions it needs for cookies, scheduled tasks, Native Messaging, and local state. The Zhihu and Weibo host permissions are optional and must be granted by you on purpose. Auto-sync fires on Edge startup, every 15 minutes, and whenever a target cookie changes — and after a cookie change it first merges for a short window so it doesn't upload in a flurry.
Native Hostis the bridge between the browser extension and your machine's system capabilities. The extension never touches your SSH private key, and no server connection details are baked into the extension package. The Host only accepts a constrained server address, port, and a single-level key filename under ~/.ssh/, and then calls the system's OpenSSH.
The restricted SSH accountis fixed as rsshub-sync. It has no ordinary shell and isn't in the Docker group; on the server side a forced command confines it to the sync protocol. Cookies travel over SSH's standard input, so they never appear in the command arguments.
The server makes every decision that can affect RSSHub: checking input, verifying the upstream, saving the candidate, updating the live env, inspecting the Compose file, rebuilding the target service, waiting for the health check, and rolling back on failure. A systemd timer keeps those checks running even when the Mac is asleep or Edge is closed.
Why it doesn't swap the cookie on the first failure
When it judges the session state, the project probes the Zhihu and Weibo login endpoints and the RSSHub health status directly, rather than watching for "new articles." The server classifies each result as an authentication failure, a transient fault, or a healthy state: a clear authentication failure is counted and confirmed cumulatively;403,429,432, timeouts, and 5xx are treated as transient upstream faults and don't trigger an immediate cookie rotation.
That distinction matters. Rotating cookies blindly during rate-limiting not only fails to fix anything, it can even replace a session that still works. Auto-repair is only meaningful when the live cookie has been confirmed dead and the server already holds a validated candidate. If there's no usable candidate, Bark tells me to go back to Edge and log in again, and persistent transient faults — plus the eventual recovery — are alerted according to policy.
Zhihu and Weibo are tracked independently. Trouble on one service never clears or blocks the other's valid session.
Treating failure as a normal branch when updating RSSHub
On first hookup, the installer migrates ZHIHU_COOKIES,WEIBO_COOKIES, and TWITTER_AUTH_TOKEN from the environment of the target RSSHub service in the Compose file to secrets/rsshub.env next to it, loading them with env_file's raw format. That way characters like $,# inside cookies are never re-interpreted by Compose, and the secret file is tightened down to root-only readability.
What happens afterward isn't "write a file and pray." The server holds a lock, runs the change as a transaction, writes the new env atomically, checks the Compose config first, rebuilds only the target RSSHub service, then polls the health check. If any step fails, it restores the old env and re-establishes the previous running state. It never runs docker compose down, never rebuilds Redis or browserless, never pulls images, and never deletes volumes.
This part deserves coverage more than "how to get a cookie": the most dangerous thing about automation usually isn't what it can't do, but the ambiguous in-between state it leaves behind when it only finishes halfway. Here, installation, migration, switching, and uninstallation all treat interrupted-recovery, boundary checking, and idempotency as the normal path.
Where the credentials live
A cookie is, at bottom, a login credential. The project keeps its exposure path as short as it can:
These measures can't erase the trust boundary of the host machine itself. Anything running with your Mac's current-user privileges could still attack the browser or read the SSH files that user can read; and anyone with server root or Docker admin rights can read the cookies inside the RSSHub container. The project protects the sync path — it isn't a sandbox escape for an already-compromised OS.
Installation
A standard install is done across three ends. First, install the Native Host under your Mac's current user and copy the project public key the installer prints at the end:
Next, connect to the server over ordinary SSH for the first time, verify and accept the host fingerprint. In the same root session run the server installer, choose your RSSHub Compose file when prompted, and paste in the public key you just copied:
Finally, grab the extension ZIP from GitHub Releases and install it at edge://extensions via "Load unpacked". Open the extension's connection settings, confirm the Native Host is reachable, fill in the server address and SSH port, pick the rsshub-cookie-sync dedicated key, authorize the Zhihu and Weibo site permissions, and run the first sync.
Please don't paste cookies, your Bark Device Key, your SSH private key, real server addresses, or unredacted Compose output into an Issue, a chat, or a screenshot. Releases also ship SHA256SUMS, so you can verify the downloaded file before a real install.
Scope and trade-offs
Right now the project targets macOS, the Microsoft Edge Chromium Default Profile, and a self-hosted RSSHub running Linux, systemd, Docker Engine, and Docker Compose v2.30+. The supported providers are Zhihu and Weibo; at runtime the server relies only on the Python 3.9+ standard library. Node.js is used only for testing the extension.
It won't type passwords for you, won't bypass CAPTCHAs or MFA, and can't magically stretch out a session that has already expired. When a human login is needed, the right move is still you going back to the browser and signing in. What this project does is judge clearly when it's time for you to come back, and reliably handle all the mechanical steps around it.
As of this writing, the latest version is v1.1.3. The repo contains the Edge extension, the macOS Native Host, the Linux server, install and uninstall scripts, plus automated tests covering protocol validation, key migration, transactional rollback, Compose migration, and monitoring policy.
Project home
Code, installation docs, troubleshooting, and the security policy all live on GitHub: Jaaayden/rsshub-cookie-sync. The project is MIT licensed. If you also self-host RSSHub and keep getting derailed by expired sessions, it might save you from a chunk of repetitive, error-prone maintenance.