Troubleshooting

Konode is not syncing, and there is no error

Check the obvious three in order. First, is a backend actually connected, or did setup stop halfway? Second, are any data types turned on? All four are off until you enable them, so a connected backend with nothing enabled will sit there doing exactly nothing. Third, run a manual sync from the popup to see whether it is a scheduling problem or a connection problem.

If a manual sync works but automatic ones do not, your browser is probably suspending the extension's background worker to save power. Manifest V3 service workers are allowed to be shut down when idle. Keeping the browser open and the device awake is the practical workaround.

Bookmarks are not syncing between my two browsers

The usual cause has nothing to do with bookmarks in particular. Both devices need the same backend and the same account on that backend. A second Google account, or a different repository, gives you two separate sync sets that will never meet. Confirm the account and the folder or repository name match on both.

History is not syncing, but bookmarks are

History is one of the three streams that stay off until you switch them on, and switching it on is what triggers the browser's permission prompt for it. If that prompt was dismissed, the permission was never granted. Turn the stream off and on again, and accept the prompt when it appears.

Firefox for Android is the exception that this will not fix. It does not grant the history permission on request, so Konode marks history unavailable there and syncs your open tabs only.

A bookmark I deleted came back

This is what tombstones are meant to prevent: Konode records a deletion as an explicit event rather than inferring it from an absence, so the deletion travels to other devices instead of being undone by them.

If it happens anyway, the usual cause is a device that was offline when you deleted and had an older copy, combined with a conflict rule set to prefer that device. Check your conflict setting. If it is on "always prefer this device" somewhere, that device wins even when it is out of date. This is worth reporting with the details, since a deletion coming back is the exact failure the design targets.

Two devices disagree and I do not know which won

That is your conflict rule deciding. It is one of: newest change wins, always prefer this device, always prefer the other one, or ask each time. If you want to see each decision rather than have it made for you, switch to manual resolution and Konode will hand you the choice from the popup.

Two things to know before you do. The question names the device but not the bookmarks, so it tells you two versions exist and not what is in either. And it is asked on the first sync between any two devices whether or not they actually differ, because what it compares is whether the two files are identical byte for byte, which they never are. Both are being worked on.

Google Drive sign-in fails on Brave, Helium, or ungoogled-chromium

These browsers do not provide Chrome's built-in identity API, so Konode uses an OAuth PKCE flow instead. It opens a normal sign-in page rather than a native dialog. If it fails, the usual causes are a popup or redirect being blocked by the browser's own shields, or a privacy setting stripping the OAuth redirect. Try loosening shields for the sign-in, then restoring them afterwards.

Google Drive sign-in returns "redirect_uri_mismatch" on Orion or Quetta

Try the sign-in again first. This was a redirect address missing from our OAuth client, registered in September 2026, so there is nothing for you to update or reinstall. Both browsers support the call Konode uses to ask the browser for its own redirect address, but hand it back with the path dropped, so Google was sent a form of it our client did not list. The extension ID in the request was correct the whole time, which is what made this look like a fault in Konode rather than a missing registration.

If it still fails, read the Request details: redirect_uri=... line on Google's own error page. A different extension ID there means your browser assigned Konode an ID of its own, which cannot be registered ahead of time, and GitHub or WebDAV are the backends to use on that browser. The Activity log will not tell you which of the two you are in: from Konode's side a refused redirect looks the same as a closed window, and is recorded as a cancelled sign-in.

Google Drive is switched off in Orion

Not something you can change in settings. Orion's WebKit engine exposes the OAuth bridge Konode needs, but throws a native error the moment it is called instead of opening Google's consent screen. Konode disables the Drive option there rather than letting setup fail halfway through. WebDAV is the verified way in on Orion, and a device set up with it joins the same sync group as the rest of your devices. GitHub works there too, reported by someone running Orion RC rather than tested by us.

In Orion, bookmarks arrived split in two, or a session restored one tab

Both are known, and both are WebKit rather than your setup. Orion has a Bookmarks Bar and a Favorites, and Konode treated both as the bar, so an arriving tree landed partly in each. Separately, WebKit allows one programmatic tab per click, so restoring a session opened the first tab and silently dropped the rest.

Both are fixed in 1.3.0, along with a third one: a first install on Orion showed no setup wizard at all, and the popup now offers a way into setup until you have chosen a provider. None of the three has been run on an Orion device yet, so if you are on an older version, or on 1.3.0 and still seeing either, check both bookmark roots after a large first sync and treat a restore as opening the first tab.

GitHub sync stopped working on its own, or returns 401

Almost always an expired fine-grained token. They have a mandatory expiry date. Generate a new one, scoped to the same single private repository with read and write access to contents, and paste it into settings. Nothing on the backend is lost while the token is dead; syncing just pauses.

WebDAV will not connect, or returns 401 or 403

Work through these in order:

• The URL has to be the WebDAV endpoint, not your normal web login. On Nextcloud that means https://your-server/remote.php/dav/files/USERNAME/, not the address you use in a browser.
• HTTPS is required, with a certificate your browser already trusts. Self-signed and expired certificates fail, and so does plain HTTP.
• Use an app password if your provider offers one. Accounts with two-factor authentication frequently reject the main account password for WebDAV, which is what a 401 normally means here.
• Check the path exists and that the account may write to it. Some servers will not create missing parent directories on demand. A 403 normally points at one of those two rather than at your credentials.

Can I use Mega, Filen, Dropbox, or OneDrive?

Mega and Filen are not available yet. Mega is the one with design work behind it. Filen sits behind Mega and may not happen at all, because we would rather leave a backend out than force it in. Dropbox and OneDrive are not supported directly. If a provider offers a WebDAV endpoint, the WebDAV backend will work with it, and Filen can serve one from your own machine if you run its command line tool, which nobody has reported trying with Konode. See the roadmap.

My second device says the passphrase does not match

Every device has to use the identical passphrase, and Konode deliberately tells you about a mismatch instead of silently producing an unreadable second copy. Re-enter it carefully, watching for a different keyboard layout, autocorrect capitalising the first character, or a trailing space picked up by copy and paste.

I lost my encryption passphrase

Then the data already uploaded cannot be decrypted, by you or by anyone else. No Konode server holds your key, so there is nothing to reset and no recovery path. That is the tradeoff end-to-end encryption makes.

To start over: delete Konode's files from your backend, set a new passphrase, and sync from the device whose local data is still intact. Your bookmarks in the browser itself were never encrypted and are unaffected.

Can I turn encryption on after I have already been syncing?

Yes, but the files already on your backend were written in readable form. Turning encryption on affects what gets written from then on. If the point is that nothing readable should remain, delete the existing Konode files from your backend after enabling it, then sync again.

Restored history shows today instead of the original visit dates

On Chromium this is a browser limitation, not a bug. Extensions cannot set an arbitrary original visit time on a history entry, so restored entries carry the moment they were synced. Firefox does allow it, so the original times survive there. This is why history restore is described as best-effort.

Konode lists my missing extensions but will not install them

Intentional. Konode holds a read-only permission on your extension list: it can tell you what is missing and link you to each store page, and it cannot install or remove anything. Installing an extension always takes your own click in the store.

Passwords are not syncing

Konode does not sync passwords and cannot. Extensions have no access to the browser's native password store, which is a browser security boundary rather than a missing feature. Use a dedicated password manager such as Bitwarden, Proton Pass, or a self-hosted Vaultwarden.

The install asked for very few permissions

Also intentional. History, tabs, and extension-management permissions are requested at the moment you turn those data types on, not up front, so an install you never configure holds almost nothing.

The add-on disappears every time I restart Firefox

That happens when it was loaded through Load Temporary Add-on, which Firefox discards on restart. Install from Firefox Add-ons instead and it stays put.

Which Firefox-based browsers work?

Firefox itself, and Firefox-derived browsers such as Waterfox. Anything that installs a standard signed Firefox extension should work. Firefox for Android is the exception in what it can sync: it has no bookmarks API and will not grant the history permission on request, so Konode shows both as unavailable there and syncs your open tabs only.

How do I remove everything Konode has stored?

Two places, and you control both. On your device, uninstalling the extension clears its local data, including credentials, settings, and the activity log. On your backend, delete Konode's folder or repository contents directly through Google Drive, GitHub, or your WebDAV server. Nothing is held anywhere else, because there is nowhere else.

How do I switch backends?

Connect the new one in settings. Backends do not migrate between each other, so treat it as a fresh start: your browser's own bookmarks are untouched and will be written to the new backend on the next sync. Clean up the old backend's files yourself if you want them gone.