Changelog

What changed in each version of knotless for those who use it, from the change files in .changeset/ (see knope.toml).

0.12.0 (2026-11-08)

Features

A repository's crates can be published and used with Cargo

knotless-serve answers Cargo's registry protocol for each repository, so cargo publish, cargo yank and cargo search work with index = "sparse+https://knotless.dev/cargo/<did>/<repo key>/", and the token is <handle>:<app password>.

Pulls, issues, diffs and files are MCP resources

knotless-mcp and /mcp offer resource templates, so a client that reads MCP resources opens a pull, an issue, a pull's diff or a file by a URI like its page's, as knotless://alice.test/proj/pull/<did>/<rkey>/diff, answered as the matching tool answers.

Merge a pull by itself once its checks pass

knotless pull merge <url> <pull> --auto sets a pull to merge by itself once its checks pass, on a branch with no merge queue. The runner that lands the repository's merge queues merges it then. A push by anyone who may not merge it, or retargeting it, cancels it, and --auto --undo cancels it, as the pull's author may too. pull show says where it stands. The MCP tool is pull_merge with auto, and undo. Logging in again gives an existing OAuth login the permission to do it.

The pages set a pull to merge when its checks pass

A pull's merge box offers Merge when checks pass while its checks run or fail, says who set it, and cancels it.

The merge queue is off until a branch's rule turns it on

knotless pull merge --queue and the pull_merge tool's queue now refuse a pull unless the branch it lands on is protected with --queue. Turn it on with knotless branch protect <url> <branch> --queue, and every pull into that branch then lands through the queue. A pull already queued keeps its place.

Withdraw a bad release with knotless release yank

knotless release yank <url> <package> <version> withdraws a version without breaking anyone who pinned it: its files can still be read by version, but it is no longer the latest, and the releases page marks it Yanked. --undo takes that back. The MCP tool is release_yank. Logging in again gives an existing OAuth login the permission to do it.

A review agent's rounds count only its requests for changes

knotless-agent review --rounds now limits how many times it asks for changes on a pull, not how many times it reviews it. A pull it approved is reviewed again at each later push, and the command is told the commit it approved (approved), and how many times it has asked for changes (changes). A request for changes is no longer carried to a head that only merges the base in when the pull's title or body was edited after it.

An agent watching an owner finds their private repositories shared with it

knotless repo share leaves the account shared with an invite at the appview, and knotless-agent --owner <handle> watches, besides that account's public repositories, every private one it shared with the agent's account, so a reviewer need not be told each private repository by name.

Fixes

Commands reading one repository at once no longer fail on its history

Two commands fetching the same repository at once could fail with git commit-graph: Could not read, when one found a commit whose parents the other had not fetched yet. Fetches now take turns.

A connector whose login has ended asks you to sign in again

When your PDS ended the login a knotless server keeps for your connector, its tools carried on as no one: private repositories read as not there, and writes said to run knotless login. The server now answers so that your assistant has you sign in again.

A git killed part way no longer leaves a repository unreadable

A server or command stopped while it set a mirror's refs could leave git's lock file behind, and every later read of that repository then failed with cannot lock ref. The lock is now cleared the next time the refs move.

An OAuth login is kept when refreshing it fails

When an OAuth login's refresh failed for any reason, knotless logged in with KNOTLESS_PASSWORD instead and saved that over the OAuth login, which can't read private repositories. Now the OAuth login is kept and tried again, and the failure is logged. The password stands in only once the server turns the refresh down for good.

A merge queue's next batch goes first once the batch before it lands

A batch built ahead of one still being checked waits for a job behind pulls' runs. Once the batch under it lands, a runner now ranks what is left of it with pushes to the default branch, so it lands next instead of waiting behind every pre-flight queued meanwhile.

A merge queue batches a pull as soon as its pre-flights pass

A runner landing a merge queue now looks again the moment a pull's run ends, on it or on another runner the repository names. A pull whose last pre-flight passed used to wait for the runner's next sweep, up to 10 minutes, before going into a batch.

A release that fails to publish says why

Publishing a version now says it is published already only when it is. Any other failure, such as a login that was refused, gives its own reason.

0.11.0 (2026-11-05)

Features

Pulls based on a pull's branch move when it lands

When a pull lands and its branch goes, open pulls based on that branch now target what it landed on, and show only their own changes. Before, they stayed on the old branch, which was kept for them.

A stack queued lands in turn

Queue each pull of a stack and each waits for the one below it, then moves to what that one landed on and lands in turn. knotless queue list lists one waiting as stacked. Leaving the queue takes those waiting on the pull with it.

Fixes

A moved pull lands with an older git

Merging or queueing a pull moved off a landed pull no longer needs git 2.40, and git failing during a merge is no longer reported as a conflict.

Waiting pulls list as they land

knotless queue list lists pulls waiting for the pull below them lowest first, the order they land in.

0.10.0 (2026-11-05)

Features

Commands are grouped

Every knotless command is now knotless <group> <action>: knotless pull create, knotless repo star, knotless run list, knotless branch protect. An opposite is --undo on the action, so unstar is repo star --undo. Only login, logout, upgrade and status stand alone. The old names, such as knotless pull and knotless checks, work for one more release and then go. knotless --help lists the new ones. The MCP tools are renamed to match, <group>_<action>: repo_star, pull_merge, run_list. A tool is now the twin of the command of its name, so what the CLI could do and the tools could not, and the other way round, is added: repo tree, repo read, repo log, pull update-branch, pull dismiss-review and release read on the command line, and the commands that lacked tools, in the tools. Update any MCP client config that names a tool.

Private repositories have sites

knotless repo site now deploys a private repository's site. It is kept in the repository's space and read only by its members, at a host of its own, https://<repo key>-<plc id>.private.knotless.page/. A member who opens it logs in at knotless.dev if they are not logged in already. Someone who is not a member gets a 404, and a member you remove stops reading it within a minute.

The owner cancels runs

knotless run cancel <url> --ref <name> | --pull <at-uri> [--workflow <name>], and the MCP run_cancel tool, ask a repository's runners to cancel a ref's or a pull's runs going or waiting, a deploy's too, or only one workflow's.

0.9.0 (2026-11-04)

Features

A keeper for the merge queue

knotless-agent keep is an account that keeps the pulls the merge queue turned away moving. One turned away for a conflict that is only lines both sides added it brings up to date and queues again. Where both sides changed the same lines, it tells the author on the pull which files. Keeper: off on a line of a pull's body has it left alone.

Deploy a repository's website

knotless site <url> <dir> deploys a directory as the repository's website, served at https://<owner>.knotless.page/<repo>/, uploading only the files the live site lacks. --fallback serves a single-page app, --not-found a 404 page, and --down takes the site down.

Fixes

A pull held for a review no longer tells its author to approve it

The message for a pull that lacks a review now says that anyone but its author who may write can approve it, and that the owner merges past it with --force, their own pull too.

Pushes and fetches no longer wait on a listing of the packs

Each ref now names the pack holding its commit, so git fetch reads just those packs, and git push, git ls-remote and a fetch with nothing new no longer list the packs at all. On a repository with many recent small pushes that listing ran to megabytes, and about half of each call's time. The owner's git push now starts knotless compact --due after every push, which counts the packs itself and compacts only at KNOTLESS_COMPACT_THRESHOLD.

0.8.0 (2026-11-04)

Features

Code search loads more results

The code search page shows its first 20 files, then loads more below them, 200 files at most. dev.knotless.searchCode takes a cursor for the page after.

Code search

Search finds code: pick Code beside Repositories, or the palette's code row, to search the default branch of every public repository, with repo:owner/name for one and lang: for a language. Each match is shown in its lines, highlighted as its file is. knotless status shows the server's code search index: whether it answers, and the repositories, shards and size it holds.

Dismiss a review

knotless dismiss <url> <pull> <reviewer> <reason> dismisses a review as the owner or a collaborator, and so does MCP's dismiss_review. The review counts for nothing until its reviewer reviews again, so a gate's request for changes no longer needs --force, even on your own pull. show marks a dismissed review.

Go to file

A repository's code page has Go to file beside Code, and t opens it: type part of a path to find any folder or file at the branch shown, and Enter goes to it.

The install script brings the runner, labeller and reviewer

curl -fsSL https://knotless.dev/install.sh | sh now installs knotless-run, knotless-triage, knotless-agent and its knotless-claude-review script beside knotless, git-remote-knotless and knotless-mcp. A runner, labeller or reviewer no longer needs a clone of knotless and Rust to build it. Pinning KNOTLESS_VERSION to a release from before these shipped still installs the first three.

Merges always name their pull, and a push that lands a pull merges it

knotless merge into a branch that is not protected as linear now always makes a merge commit naming the pull, even where it could have fast-forwarded, so the branch's history says which pull each commit came from. Its method is merge or squash; fastForward is no longer made. A pull whose head is already on its base is marked merged without moving the branch.

A git push that puts an open pull's head on the branch it targets now marks that pull merged, and closes the issues it names, as knotless merge would, saying so on git's output. The pages link each commit to the pull that brought it in, whether it was squashed, merged or pushed.

A branch's gates are its required reviewers

Every pull into a protected branch now asks the gates its rule names to review it, so they show among its reviewers before they review, marked "Required reviewer for main" on its page. unask-review refuses to stop asking one: change the rule instead.

A stopping runner hands over to the next one

On SIGTERM, knotless-run finishes the runs it has started, along with a merge-queue batch's runs and those at a running deploy's commit. It writes a note beside its state file, so a runner started beside it takes up everything else at once. The new runner leaves the old one's checks and caches alone, and takes no job the old one's runs hold.

Update a pull's branch

knotless update-branch <url> <pull> and the MCP update_branch tool merge a pull's base into its branch and push it, with no checkout, as GitHub's Update branch button does. Where both sides only added lines at the same place, as two pulls each adding a section to one docs page, the base's lines come first and the pull's after; any other conflict is refused, naming its paths.

Workflows run after others

A workflow can name others in after: the runner starts it only once their checks at the same commit have passed, and it holds no job while it waits. If one fails or is cancelled, it does not run.

Fixes

knotless login works in Chrome and Firefox again

The login page's address had grown past what Chrome and Firefox send back to it, so approving a login on bsky.social and other PDSes failed with "Invalid referer". knotless login now asks for the same access in a shorter form. A login made before stays current.

The MCP pull_diff tool gives a long diff a few files at a time

A pull's diff too long for one answer used to be cut off by the MCP client, so an agent read only its first files. Now pull_diff lists the files of such a diff instead, with how many lines each adds and removes, and takes paths to give those files' parts of it.

The queue says when a pull's pre-flight failed

knotless queue lists a queued pull whose pre-flight failed as failed <workflows>, and show says which failed, rather than queued and "running its checks again" while nothing runs, until the runner ejects it or runs it again.

A review agent reads a pull again when its body answers a request for changes

After knotless-agent review asks for changes, editing the pull's title or body has it review the pull again at the same head, as one of its rounds, so a request about what the pull says no longer needs a push to clear. knotless-claude-review also no longer asks for changes over what a required check already fails the pull for.

0.7.0 (2026-11-03)

Features

Pulls and issues are assigned, and maintainers ask for reviews

The owner and collaborators assign a pull or an issue to accounts with knotless assign and take them off with unassign, and ask anyone to review a pull, not only its author, with knotless ask-review and unask-review. Each stops asking only those it asked. knotless show lists the assignees, knotless list -q and the MCP's list_items take assignee:<handle, did or @me> and no:assignee, and the MCP's assign_item does either. Those assigned hear of it as an assigned notification, and those asked as a review-requested one. The pages do the same under an item's title.

An organization's admins change its repositories' settings from the command line

knotless describe, archive, compact, protect, unprotect, labels, triagers, agents, share, unshare and runners, and the MCP tools that do the same, now work on an organization's repository from an admin's own login. Not logged in as the owner, they ask the appview, which makes the change as the organization. Log in again (knotless login) if your login is older than this, so it may ask. Renaming, deleting and transferring a repository still take the organization's own login, on the pages too.

A branch waits for a review agent's verdict with knotless protect --gate

knotless protect <url> <branch> --gate <handle> names an account, such as a review agent, whose review of a pull's head the branch waits for, though it may not write to the repository. The merge queue holds a pull until the gate has reviewed its head, and a request for changes from it blocks merging and queueing until it reviews again. An approval of the head from the owner or a collaborator, given after the gate's review, stands in for it. knotless rules lists each gate, merge --check says a review of its head from @<gate> while one is awaited, and MCP's protect_branch takes gates. knotless-run's --review-wait <secs> (30 minutes) is how long the queue waits before ejecting a pull no gate has reviewed.

A branch's gates are named on its settings page

A protected branch's settings on the pages now have "Wait for a review from", which names an account, such as a review agent, as a gate of the branch by its handle. The page lists each gate, with Remove to take it out, as knotless protect --gate does.

Fixes

knotless checks --images keeps the newest run's pictures

When the checks listed hold more than one run of a workflow, as a branch's reruns or a pull's heads do, an older run's picture no longer overwrites the newest's of the same name. The older one is saved beside it, named for its commit too: look notifications-desktop-light 450b27ae11f7.webp.

Exclusive labels with no scope stand together, and a failed retarget changes nothing

An exclusive label with no / in its name no longer takes other such labels off: only labels in the same scope, such as priority/high and priority/low, rival each other. knotless retarget with both --base and --head checks the head first, so one refused for its head no longer moves the pull's base. Several workflow files with names that are not valid each give their own error in the one invalid check, rather than a duplicate-name error. knotless queue and knotless uses update no longer panic on a commit ID shorter than 12 characters, and the gateway takes SHA-256 commit IDs as pushes do.

The page after logging in is easier to read

The page the browser shows once you have approved a login now has a heading and the look of knotless's own pages, in light and dark, and says so when the server refused the login rather than that you are logged in.

A merge no longer leaves a pull open when its head branch cannot be deleted

Merging a pull whose head branch is protected keeps that branch, and says why, instead of trying to delete it. A delete that is refused for another reason no longer fails the merge after the target has moved. A git push also no longer fails when the compaction after it does, and KNOTLESS_INLINE_MAX is held to 262144 bytes, the most a pack record takes.

0.6.0 (2026-11-02)

Features

knotless admin logs reads the lines the appview logged

An appview's operator can read the lines it logged, without SSH: knotless admin logs --trace <id> shows one request with the calls it made and how long each took, and --message, --level and --min-ms show the last of the rest. The MCP logs tool does the same. The appview keeps them across deploys, for 30 days at most, and logs each read with who asked.

An organization's admins change its repositories' settings on the pages

An admin who joined an organization now sees the Settings tab on its repositories, and changes everything there as the organization: description, branches and their rules, labels, collaborators, triagers, runners and secrets, and archiving. Transferring and deleting a repository stay with the organization's own login.

Deleting a branch deletes its record

Deleting a branch or tag now deletes its ref record from your PDS, rather than leaving an empty one so that its count of moves never repeats. A new ref starts its count at the time instead. Compaction removes the empty records older clients left once they are a day old, so a repository that has had hundreds of branches reads only the ones it has now on every push, fetch and page.

Upgrade every client that pushes: an older one making a branch again under a name deleted less than a day before can have its pushes to it refused until the next compaction.

A shared step can be passed a secret under the name it asks for

A uses step's secrets can be a map from the name the step file asks for to the workflow's own, as secrets: {SSH_KEY: DEPLOY_SSH_KEY}: its steps see the value as SSH_KEY, and nothing as DEPLOY_SSH_KEY. A list still passes each secret under its own name.

A private repository's pulls, issues, comments and checks are named by their URI in its space

knotless names a record in a private repository's space as atproto's permissioned data proposal does, at://<owner>/space/dev.knotless.space/<name>/<author>/<collection>/<rkey>, wherever it gives one: what knotless pull, issue, comment and checks print, what show and list name, and what new records written into the space refer to. A URI in the public form, at://<author>/<collection>/<rkey>, is still taken for one in the repository being asked about, and records written before are read as they were. A knotless older than the one that reads both forms does not find a record named in full: upgrade with knotless upgrade.

Watch a repository, and subscribe to or mute a pull or issue

knotless notifications watch <url> [all | releases | ignore | participating] chooses what you hear of a repository: all it does, its releases alone, or nothing. knotless notifications subscribe <at-uri> hears of every comment on a pull or issue, mute hears nothing of it but a review asked of you, and unsubscribe goes back to hearing of it as your part in it says. knotless notifications subscriptions lists what you chose. The MCP subscribe tool does the same. Notifications gain the reasons subscribed and watching. They call two new appview methods, so a login made before this needs knotless login again.

Workflows run on a schedule

A workflow's on: {schedule: [{cron: '30 3 * * *'}]} runs it at the default branch's tip at the minutes its cron expressions name, in UTC, at most every five minutes. Its steps see KNOTLESS_SCHEDULE, the expression that ran it, and its log says ==> on its schedule. The runner reads schedules from the default branch's tip as it starts and whenever that tip moves. A time that comes while the last run is still going is skipped. knotless workflows lists each workflow's schedules at the default branch.

Fixes

A feature branch's pulls start from its own warm caches

A branch whose pushes and pulls both run a workflow, as on.push.refs and on.pull.base both naming refs/heads/feature/* do, keeps that workflow's caches for itself: each passing push to it leaves what the pulls into it start from, and a pull landed there at the tree it was checked at is taken as the push's run, caches and all. A branch with none yet starts from the default branch's, and its caches go when it is deleted.

knotless checks --ref takes a branch named bare

knotless checks --ref main lists the checks of refs/heads/main, as rerun and workflows read a bare name, rather than none; a tag of that name, when there is no such branch. A branch deleted since, as a merged pull's, still names its checks. The MCP checks tool's ref takes one the same way.

knotless admin logs --trace reads up to 500 lines of the request

A read by trace now answers up to 500 lines unless --limit says fewer, instead of the last 100, so a long request's first lines are not cut off. Lines serve fails to write to its log store, as when another serve holds the file during a deploy, are kept and written with the next batch instead of lost.

An organization's admins set its repositories' secrets

knotless secret <url> set, ls and rm, and the MCP secret tool, now work on a repository an organization owns when you are logged in as an admin who joined it, not only as the organization's own account. The values are sealed as the organization's, so its runners open them as before.

Queueing says to read an ejection's logs before queueing again

knotless merge --queue ends by saying to read an ejected pull's check logs before queueing it again. The MCP merge tool's description says the same, says to merge the target branch in just before queueing, and says that a pull conflicting only with one ahead of it waits for that one rather than merging its branch in.

A queued pull's record names the head it was queued at

knotless merge --queue, and the MCP merge tool with queue, write the pull's head into its dev.knotless.queue record, as an ejection already does, and knotless show --json gives it. The queue's history then says whether a pull queued again after an ejection had changed.

Queueing a pull again at the head it was ejected at says so

knotless merge --queue says when the pull is going back into the queue at the very head the queue last ejected, and why it was ejected: unless that was not the pull's doing, it will be ejected again. The MCP merge tool answers it as queued.ejectedBefore, and dev.knotless.queuePull as ejectedBefore.

A queued pull says what it waits for

knotless show, the MCP show_item tool and knotless queue --json say what a queued pull in no batch is waiting for: Queued, 2nd of 3, running its checks, running its checks again on main as it is now when one failed on an older tip, or ready for the next batch. Before, each just said Queued, except while a pre-flight was running. --json also gives each one's stage, its pre-flights' newest runs (preflights), and when the batch ahead of it started (ahead).

Reading a repository with many deleted branches is faster

A repository keeps a record for every branch it ever had. Past the first 100, knotless now reads those records in ranges side by side rather than one page after another. Pushing to, cloning and listing a repository that has had hundreds of branches, as a busy one does, takes a fraction of the time, for example 0.37 seconds rather than 1.7 for 590.

A private repository read for longer than a space credential lasts goes on reading

A space credential lasts minutes. What reads a private repository for longer, as knotless-run watching one does, renews it before it runs out rather than failing every read after with JwtExpired, and a session read with renews the same way.

A record in a private repository's space can be named by its full URI

Wherever knotless takes a pull's, an issue's or a comment's at:// URI, as knotless show, comment, merge, checks --pull and a pull's Fixes, it reads a private repository's record by its URI in the space too, at://<owner>/space/dev.knotless.space/<name>/<author>/<collection>/<rkey>, as atproto's permissioned data proposal names it, as well as by at://<author>/<collection>/<rkey>.

knotless admin stats says which queries were slow, why actions failed, and which crawlers came

An operator's knotless admin stats, and the MCP stats tool, now list the index's slow statements with how often each ran slowly, their mean and their longest; why MCP tool calls failed, with like errors counted together; and the requests each crawler or script made, by its user agent. Each is kept for 30 days.

0.5.0 (2026-11-01)

Features

A workflow step can use a step another repository shares

A step with uses: <owner>/<repo>/<step>@<version> runs the steps of .knotless/steps/<step>.yml in that repository, at the commit .knotless/uses.lock pins it to, with the inputs with gives, only the secrets the step passes it, and its own repository checked out beside the checkout as KNOTLESS_STEP_DIR. A step file can use shared steps of its own. Release a step with knotless publish <url> @step/<step> <version> .knotless/steps/<step>.yml --commit <sha>, and pin the ones a checkout uses with knotless uses update. Each step is now given its secrets as it starts, rather than the container holding them all.

show lists the pulls that mention an issue

knotless show on an issue prints mentioned in <pull> for each pull on the repository whose title or body names it, oldest first, ending , to close it where the pull names it after a closing keyword. MCP's show_item gives the same as mentionedBy.

A login and a gateway's grant name knotless's own space types

knotless login asks for space:dev.knotless.space and space:dev.knotless.orgSpace, each with the collections knotless writes there, in place of every space of every app (space:*); knotless delegate asks the same of a gateway's grant. A login or grant from before still works, and is asked for again as any older one is.

A workflow step can run only at some refs

A step with on: {refs: [refs/heads/main, refs/tags/*]} runs only at a push to, or a run asked for at, a ref those patterns match, as on.push.refs are matched; anywhere else it passes unrun, listed skipped, its log saying why. A pull's run and a merge-queue batch's run are at no ref, so such a step runs in neither. On a step with uses, its on holds for every step the shared step comes to, beside their own.

Themes of your own

The pages' Appearance settings make a theme of your own colours, checked as you choose them for text that reads on what it is drawn on, and publish it as a dev.knotless.theme record for anyone to choose from Appearance. Choosing one copies its colours into your preferences, so its author changing or deleting it later leaves your pages as they are. Logging in again asks to write dev.knotless.theme records.

The command line does the same: knotless theme check, publish, use and delete, and knotless themes to find them; and over MCP, the theme and list_themes tools. A palette is held to the same contrast wherever it is made.

Fixes

knotless show names the command that reads an ejected pull's logs

A pull the merge queue ejected as its checks failed shows logs: knotless checks <url> --pull <pull> --log, or --queue <branch> for a batch, after where it stands. The runner no longer writes that command into the reason it records, which the web pages show beside links to the checks that failed.

An organization's space has a type of its own, dev.knotless.orgSpace

An organization keeps its invitations and hidden members in a space of the type dev.knotless.orgSpace, which has its own lexicon, so that a login can name it. Its gateway moves an organization out of its old space, of the type dev.knotless.org, as it starts and as the organization next changes, keeping each member where they stood. A hidden member's record of joining stays in the old space, and counts, until they join again: knotless org join <org> --hidden moves it.

knotless status shows the server's disk

knotless status adds a disk line: how much room is left on the disk a knotless-serve keeps its mirrors on. Under 15% free the disk shows as low among the problems, and under 5% the server counts as unhealthy.

0.4.0 (2026-10-30)

Features

Say an account is a bot

knotless profile --bot says your account is a bot, such as a runner, a triager or a reviewer, and --no-bot takes that back. The MCP server's set_profile takes bot, and the profile settings page has a box for it. A bot's profile shows a "Bot" tag, and the front page's feed leaves out what it says and pushes.

Fixes

The feed leaves out bots

The front page's feed no longer shows what a repository's runners and triagers say or push on it, which repeated what people did and crowded them out. A runner that is the repository's owner or a collaborator still shows. A pull the merge queue landed shows as merged by whoever queued it. A bot's own profile still shows everything it did.

The appview's gateway is the one its DID document names

knotless share --write, knotless delegate with no gateway named, and a runner landing a merge queue through the gateway now ask the appview for its DID instead of making one from KNOTLESS_APPVIEW's address. A runner that reaches its appview at an internal address, as one beside it does, lands its queue again rather than failing to reach a gateway that does not exist.

Private repositories work on the October 29 spaces alpha

The spaces alpha of October 29 moved spaces from com.atproto.simplespace to a policy on com.atproto.space, and creating a private repository or sharing one failed against a PDS running it. knotless now creates each private repository's space under the memberspace policy and manages its members with com.atproto.memberspace. A PDS on an older alpha can't create private repositories with this version.

0.3.0 (2026-10-30)

Features

Archive a repository

knotless archive <url> makes a repository you own read only, and knotless archive <url> --undo makes it writable again. While it is archived, pushes and commits are refused, nobody can open pulls or issues or comment on it, and its workflows stop running. Its pages show it as archived. You can also archive and unarchive it from its settings, in the Danger zone, or with the MCP server's archive_repo tool.

Hear of your pulls' failed checks and merge queue ejections

knotless notifications, the MCP notifications tool and the pages now say when checks fail at your pull's latest run (checks-failed) and when the merge queue takes your pull out (ejected), each naming the checks that failed. Either can be turned off with knotless notifications settings --off <reason>. The pages' notification settings can also show new notifications on your screen while knotless is open in a tab.

Change part of a long file without sending all of it

knotless commit --edit <path> <old> <new> and the MCP commit tool's edits replace text in a file as the branch holds it, so an agent changing one line of a long file sends that line, not the file. On a branch that moved meanwhile, edits are made in the file as it is there. knotless search and the search tool take --path/path to look only under a directory or glob, and --context/context to show the lines around each match, enough to write an edit from. The read_file tool takes start and end to read only some lines, and blame (--lines <first>-<last> on the command line) blames only some.

Notifications of one kind

knotless notifications --kind <kind> lists only mentions, reviews, comments, pulls-and-issues, checks or stars-and-follows, and the MCP server's notifications tool takes the same kind. A listing of one kind marks nothing seen, so the others stay new.

Owners give their runners secrets

knotless secret <url> set <name> [--ref <pattern>]... gives a repository's runners a secret, read from stdin, sealed to the key each runner publishes so only it can read it, and left at the appview. knotless secret <url> ls lists them, never a value, and rm takes one back. The MCP server has a secret tool to match. A runner reads them for each run whose workflow lists a name its secrets file does not grant. knotless runners <url> remove deletes the secrets sealed to that runner, and add says which secrets must be set again to reach it.

A read-only knotless-mcp, and reviews of private repositories

knotless-mcp --read-only offers only the tools that read, and runs no other, whatever account it is logged in as. The review agent reads through it with its own login, so it reviews the private repositories shared with it, and a repository says what it wants of its reviews in .knotless/review.md on its base branch.

Topics and collaborators on a repository

knotless describe <url> --topic rust --topic cli names what a repository is about, and --topic '' drops its topics. They show under its description, each linked to the other repositories about it, and the MCP server's update_repo tool and the repository's settings change them too. A repository's page also shows who may push to it besides its owner.

Review agents

knotless-agent review runs an account of your own that reviews the pulls asking it for a review, as GitHub's Claude review bot does. Ask it with knotless pull --reviewer <its handle> or knotless edit --reviewer; it reads the pull with Claude Code, through knotless-mcp's read tools, and writes a review with a verdict and comments on lines, then reviews again as you push, up to --rounds times. It uses your Claude subscription (claude setup-token) or an API key, and --command takes any other reviewer that reads and writes its JSON. The guide is docs/guide/reviews.md.

The reviewer can watch every repository an account holds

knotless-agent review --owner <handle> reviews the pulls of every public repository that account holds, listed again at each read, so a repository made later is reviewed without restarting the agent. Repeat --owner for more accounts, and name repositories besides as before.

knotless-run keeps a key for secrets

knotless-run now makes a P-256 key on its first start, kept in --secrets-key <file> (secrets-key.json beside its state file by default), and publishes its public half as its dev.knotless.runnerKey record. Owners will seal the secrets they give a runner to it, so only the runner can read them.

The appview keeps secrets sealed to a runner

knotless-serve answers dev.knotless.putSecret, deleteSecret and listSecrets: an owner leaves a repository's runners secrets, each sealed to one runner's key, and the appview holds only ciphertext. knotless's login asks for these methods, so a session from before asks again at its next login.

Owners manage secrets on the repository's settings

The repository's Settings, under Actions, list its secrets by name and add, replace and remove them, signed in as its owner. Each value is sealed in the browser to the keys the runners publish, as knotless secret seals it, so the appview still holds only ciphertext.

Hear of new versions, and upgrade

Once a day, knotless asks its appview for the newest release. When one is out, a command ends by saying so on stderr. knotless upgrade installs it over the copy you run. When the appview asks for a newer version than yours, because yours is known to harm repositories, knotless and knotless-mcp refuse to run until you upgrade. KNOTLESS_NO_UPDATE_CHECK turns the check off, and KNOTLESS_IGNORE_MINIMUM runs anyway.

A workflow can name the runners that run it

A workflow's runners key names, by handle or DID, which of the repository's runners run it; the others leave it be and file no check of it. knotless secret <url> set <name> --runner <handle> gives a secret to those runners alone and takes back the copy any other had, as the MCP secret tool's runners does. Together they keep a deploy and its secrets on a runner of your own while the hosted runner checks everything else.

Fixes

Clones no longer break after a branch is deleted and compacted

A clone or fetch could fail with "the remote has no pack holding" a commit of a deleted branch, such as a landed pull's. A newer pack still named that commit as a base, and compaction had dropped it. Compaction now keeps every base that the packs it leaves name.

Compaction stops rather than lose a commit

If compaction can't fetch a commit that a newer push still needs, it now stops and deletes nothing. Before, it left that commit out and deleted the packs anyway, which broke clones with "the remote has no pack holding" that commit.

A conflict is named a conflict

A 409 from knotless-serve, such as a gateway commit whose edit no longer finds its text, now says Conflict (409) rather than InternalServerError (409), so it no longer reads as the server failing.

A pull the merge queue landed shows the checks it landed on

A merged pull's page now shows the checks of the batch the merge queue landed it in, not older runs of its own heads. Over MCP, list_items and show_item name that batch's tip as merged_batch.

Joining an organization reads both places at once

knotless org join reads whether you joined publicly and in the organization's space at the same time. Switching between them no longer reads again after the organization takes you in.

Pages left open catch up when you come back

A page left in a background tab for a minute or more loads fresh data when you look at it again, and any page does the same when your connection comes back. A repository's page that loses its live connection now catches up on what it missed once it reconnects.

Pictures show at the size they were taken

A picture attached with --image, or images over MCP, keeps the size it is drawn at: a PNG saying it was made at 2x, as a Mac's screenshot does, shows at half its pixels, so a phone's screenshot is phone-sized on a pull or issue.

A run says which secrets it was not granted

A run whose workflow lists a secret the runner does not grant it now says so at the top of its log, ==> NAME is not granted to <repo> at <ref>, rather than leaving the secret silently absent. A pull's or merge-queue batch's run says the same of each, as it gets none.

An edit or reply in progress survives the page updating

A comment you are editing, or a line comment you are replying to, on a pull's or issue's page no longer loses what you typed when the page refreshes and an earlier event shows up.

0.2.0 (2026-10-29)

Features

Blame a file without a clone

knotless blame <url> <path> [--rev <rev>] prints who last changed each run of a file's lines, as git blame finds it, read from the cache mirror: the lines, the commit, its author, when it was written and its subject, tab-separated. The MCP server's blame tool answers the same as JSON, with the commit's parent and the file's path there, to blame again before it.

Reviews and merges say what they mean

merge --check lists each approval that does not count, and why, as an uncounted line (the MCP merge check as reviewsUncounted), and a merge refused for its reviews says so too. It says when the asker may not merge the pull, and counts a review written a moment ago. Over MCP, a refusal for reviews names the comment tool and merge with force rather than CLI commands; merge answers how it merged (method) and why it kept the head branch (kept); show_item gives handles beside reviewers' DIDs, marks reviews outdated, maintainer and uncounted, gives comments' mention facets, marks every comment of a resolved thread resolved, has a review's own comment name itself as review, and says draft: false; comment notes an approval that will not count; notifications says markedSeen.

Comment on a pull's lines, in threads you can resolve

knotless comment takes --line <path>:<n>[-<m>][:old] <text>, as many as you like, to comment on lines of a pull's diff, alone or as one review with --approve, --changes or a body, and prints the URI of each comment it wrote. Given a comment's URI, it answers that comment in its thread. knotless resolve and unresolve resolve a thread or open it again, and knotless show says which lines each comment is on and which answer which. Over MCP, comment takes lines and answers written too, set_state resolves a thread, and show_item gives each comment's line, reply, review and resolved. On the pages, the + beside a line of a pull's diff comments on it, or starts a review sent from the "Review changes" menu.

Delete all your knotless data

knotless delete-data <handle> lists what knotless keeps in your atproto account (your repositories, those others push to or read named, and the records of each kind), then, once you type your handle again (or pass --yes), deletes all of it: your private repositories' spaces, each public repository as knotless delete deletes one, then your pulls, issues, comments, stars, follows and the rest. knotless.dev then forgets you and logs you out. A run cut short carries on where it stopped when run again. Your atproto account, and other apps' records in it, stay. The delete_account_data MCP tool does the same, and the pages' account settings have a "Delete your knotless data" section. Logging in again asks to call dev.knotless.deleteAccountData.

Draft pulls and requested reviewers

knotless pull --draft opens a pull that neither merges nor queues until you mark it ready with knotless edit <url> <at-uri> --ready (--draft makes it one again); merge --check says draft and why. --reviewer <handle>, on pull and edit, asks someone to review your pull, and edit --no-reviewer stops asking: they hear of it as a review-requested notification once the pull is not a draft. knotless show lists both, and list -q takes is:draft, -is:draft and review-requested:<handle or @me>. MCP's open_pull and edit_item take draft and reviewers too. The pages mark drafts in the pulls list, show requested reviewers in the merge box, and let the author mark a draft ready there.

The gateway holds collaborators to required reviews and checks

Through the gateway, a collaborator moves a branch whose rule asks for reviews only by merging a pull reviewed as it asks, with its checks passed: a plain push or knotless commit to it is refused, saying to open a pull. In a repository that names runners, a collaborator's merge of a pull, pushed by any client, is refused until the pull's checks pass, as knotless merge refuses it.

Mentions

@handle in a pull's or an issue's title or body, or in a comment, now mentions that account: a full handle, with a dot, not in code or a link. Writing the record, from the command line, MCP or the pages, resolves each handle and keeps the account's DID in it as facets, so the mention still names the account after its handle changes. The pages link each mention to the account's profile, and the account hears of it with a new notification reason, mention, on unless turned off with knotless notifications settings --off mention, MCP's notification_settings or the settings page. On a private repository only those who can read it hear of a mention.

Organizations

Any account can be an organization. As that account, after delegating to a gateway (knotless delegate), knotless org add <handle> invites another account, and knotless org join <org> --public or --hidden accepts: from then on they push to each of the organization's repositories, made before or after, and read the private ones, until knotless org leave or knotless org remove. A public membership shows to anyone; a hidden one only to the organization's members, and on its public repositories a hidden member pushes and opens pulls while merging, closing and labelling take a public membership. Invitations lapse after 7 days. --admin makes an admin, who invites, removes and makes repositories as the organization from their own login (--org <org>, or knotless create knotless://<org>/<name>). knotless org members lists who is in (--public as anyone outside sees it), knotless org list which organizations an account is in, and knotless org delete --yes ends it. knotless members names an organization's members on each repository. The org MCP tool does the same, and so do the pages: Start an organization in your account menu, then a Members tab to invite, change roles, join, hide, leave and remove, and Delete organization in settings. An invitation shows in knotless notifications, MCP's notifications and the pages' notifications until it is answered or lapses, and the pages answer it there. Logging in again, and delegating again, asks to write dev.knotless.org, dev.knotless.orgMember and dev.knotless.orgAcceptance records and to call the organization methods.

knotless merge --check, and MCP's merge with check, tell a hidden member why they may not merge on an organization's public repositories: that it takes a public membership.

Pictures in pulls, issues and comments

Paste or drop a picture into a pull's, an issue's or a comment's box on the pages and it is uploaded to your account and linked where you put it, as GitHub does. From the command line, --image <file> on pull, issue, comment and edit does the same, and over MCP images on open_pull, open_issue, comment and edit_item. The record attaches each picture its body shows, so your PDS keeps it, and lets it go when an edit takes it out. A picture over 1 MB is made smaller rather than refused, and so is a profile picture, which may now be a WebP or GIF too.

A pull's diff over MCP numbers its lines

The MCP server's pull_diff tool now leads each line of a hunk with its line number in the old file and in the new, as comment's lines takes them: a + line is side: new at its new number, a - line side: old at its old number. An agent no longer counts lines from the @@ headers to comment on one.

Branches that take pulls only through the merge queue

knotless protect <url> <branch> --queue makes a branch take pulls only through the merge queue, as GitHub's "Require merge queue" does: knotless merge (and MCP merge) queues a pull into it instead of merging, saying so, and only the owner's --force merges at once. The gateway moves such a branch for no collaborator but the runner that lands the queue. knotless rules shows queue, MCP protect_branch takes it, and the repository settings' Branches page has a "Require the merge queue" checkbox for each protected branch, whose pulls' pages then offer only the queue.

Repositories show their releases

A repository's pages show what it publishes: its latest release and its packages under its name, and a Releases tab listing every version, with its notes, files and, for an image, the docker pull command. knotless-serve indexes dev.knotless.release records and answers dev.knotless.listReleases.

Repositories show their links

A repository can name up to five links, its website first, as a profile names its links: knotless create <url> --link <url> [--title <text>], and knotless describe <url> --link … to replace them, or --link '' to drop them. The MCP create_repo and update_repo tools take links, and its settings page has a Links field. Its pages show the first link under the description, before its latest release, with a count of any others that opens the list of them all. knotless describe prints a link: line for each.

Protected branches can require reviews, from code owners too

knotless protect <url> <branch> --reviews <n> makes a pull merge into the branch only once <n> of the owner and collaborators, other than its author, approve it, and while none of them has asked for changes. --code-owners also asks, for each path it changes that the branch's CODEOWNERS file (.knotless/CODEOWNERS, CODEOWNERS or .github/CODEOWNERS) gives owners, for one of them to approve it; --dismiss-stale counts only approvals of the pull's head as it is now. merge, merge --check (which lists what is missing, and CODEOWNERS lines it skipped), the merge queue, MCP protect_branch and merge, and the pages' branch settings and merge box all follow it. The owner's --force merges past it.

Revert a merged pull

knotless revert <url> <pull at-uri> [-m <reason>] undoes a merged pull as GitHub's Revert button does: one commit that undoes everything its merge brought in, on a new branch revert/<rkey> cut from its target branch, and a pull of that branch into it, titled Revert "<title>", its body linking the merged pull and saying why. It prints the new pull's URI; check and merge it, or queue it, like any pull. It stops on a conflict, naming the paths. The owner and collaborators may. The revert MCP tool does the same, and a merged pull's page has a Revert button.

Reviews stand as GitHub's do

Each reviewer's latest verdict is where they stand: a later --approve or --changes replaces an earlier one, and a comment without a verdict changes nothing. knotless show lists each reviewer as a review: line with the head they looked at, and the MCP list_items and show_item give an item's reviews in place of approvals. You can no longer review your own pull, or an issue. The pages show reviewers in a pull's merge box, and a review of a head the pull has since moved past as one of an earlier version.

Sharing for writing delegates first, and reviews say more

knotless share --write and MCP's share delegate your writes to the appview's gateway first when you have not, approved in the browser as delegate is, and say they did. Notifications name what each is about (the pull or issue, or for a star the repository) and its repository as handle/name; a review says how many line comments it holds and whether it mentions you. show_item gives each line comment its side and startLine, resolved only on threads, superseded on a review a later one replaced, and whether each requested review is still pending; list_items says draft: false too. A pull whose only code owner is its author says why it can never have that approval, and protect_branch and list_rules warn when you alone own a path.

Tag a commit without a clone

knotless tag <url> <name> [<from>] tags a commit, the default branch's or that of a branch, tag or commit, and prints it; --delete deletes a tag. The MCP server's create_tag and delete_tag tools do the same. Each release of knotless is now tagged v<version> at the commit it was built from.

The branch menu switches to tags too

On a repository's code, commits, file and blame pages, the menu that switches branches has a Tags tab beside Branches, as GitHub's does, to see the same page at a tag. Viewing a tag, the menu's button shows the tag icon and opens on Tags.

Fixes

Buttons show their action under way

On the pages, the button you pressed shows a spinner and says what it is doing, such as "Inviting…" or "Joining…", until the server answers. The rest wait, dimmed. This covers organizations and their invitations, notifications, merging, settings, labels, reactions and the rest.

Commands and MCP tools say when your login is out of date

While your login is older than what knotless asks for now, every command ends by saying so and naming the knotless login to run. An MCP tool a PDS refuses for want of scope tells the agent to have you sign in again, by reconnecting knotless in your assistant or running knotless login.

Deleting a repository leaves nothing of it

knotless delete, the delete_repo tool and the pages' Delete now also delete the repository's releases and reruns, and what you wrote about it yourself: your pulls, issues, comments, states, labels, hides, queue entries and blocks naming it, your star of it, and your reactions to those. The repository's own record goes last, so a delete cut short carries on when run again. knotless.dev drops what it kept of a deleted repository, its mirror included, and a runner drops its checks, caches and secrets grants. Logging in again asks to write dev.knotless.release records, which knotless publish needs with OAuth.

Organization changes take fewer round trips

Inviting, removing and leaving wait on fewer calls to a PDS. The gateway reads what it needs at once rather than one after another, and no longer tries to make the organization's space each time. On the pages, a change this server's gateway made is no longer indexed a second time.

Handle suggestions when inviting and sharing

On the pages, the fields that take someone else's handle suggest accounts as you type, as the login dialog does: inviting to an organization, adding a collaborator or a reader, and offering a repository to another account.

Say how to grant what a login lacks

A command a PDS refuses because your login is older than what knotless asks for now says so, and to run knotless login again. Logins now keep the scope they asked for, and the pages offer to log in again, or to delegate again, when knotless asks for more.

Collaborators and organization members hear of new pulls and issues

A pull or an issue opened on a repository is now a notification for its collaborators, and for the members of the organization that owns it, hidden members too, as it was for its owner.

Suggestions for @ while writing

Typing @ in a comment, a review, an edit or a new pull or issue on the pages suggests whom to mention: those in the thread, then whom you follow, then accounts whose handles match. Arrows choose, Enter or Tab picks, Escape closes. A mention an edit adds is heard of as of the edit, not as of when the record was first written.

A new repository never replaces one of the same name

create, fork, accept and rename refuse a name a repository of yours already has, public or private, with <url> already exists, before writing anything. On a PDS that took a create over an existing record as an update, creating a repository under a taken name replaced the old one's record and orphaned its history. The record is now written with a compare and swap that the PDS refuses when any record is there. On the web, the new repository form, the fork menu and the rename setting say as you type whether the name is free, and hold their button while it is taken.

Organization changes read at once

Joining, inviting, removing and ending an organization read what they need at the same time instead of one after another. They also read the organization's space once instead of two or three times.

Pasted pictures show in the preview

A picture pasted or dropped into a pull's, an issue's or a comment's box shows in its preview, and a profile picture picked shows before it is saved: the pages let a picture be drawn from what was pasted or picked.

Notification settings live with your other preferences

knotless notifications settings and the notification_settings MCP tool read and change which notifications you hear of through the appview's preferences (dev.knotless.getPreferences and putPreferences), which also keep the theme you choose on the pages. They behave as before, but need an appview at this version or later. Notification settings made before this were not carried over: everyone starts from hearing every reason, from anyone.

Say why a private repository can't be made yet

knotless create --private, and the create_repo MCP tool with private, on a PDS without spaces now say that your PDS can't hold private repositories yet, rather than passing on its UpstreamFailure or MethodNotImplemented. Nothing is made.

Notifications from private repositories reach members who never logged in to the appview

Members of a private repository who use only the command line or MCP now hear of what is said there: a mention, a comment on their issue, a reply. Writing a pull, an issue, a comment, a review or a state to a private repository, or sharing one, now shows the appview the repository with a delegation token, so its index has what was written. Sharing a private repository to read now names the account in the record's new readers, which the appview takes as the owner's word that they may hear of it. Someone mentioned there who is not a member still hears nothing.

A merged pull's diff once its branch is gone

The MCP pull_diff tool on a merged pull answers what its merge brought in, from the commits its merge recorded, rather than failing once merging deleted its branch.

Pushes through a gateway are credited to whoever made them

A push or commit a collaborator or runner makes through a gateway names them as pusher on the claims and refs it writes, and the feed and activity pages credit it to them rather than to the repository's owner, while the repository lists them as a collaborator or runner.

A reverted pull names its revert

Once a revert pull merges, the pull it undid names it: knotless show says reverted by, as do the MCP show_item (item.revertedBy) and the pull's page. A merged pull's compare in show_item is what its merge brought in, even once its branch is deleted, and the MCP diff tool says when there are no differences rather than answering nothing.

Usage keeps who did what for 30 days

knotless-serve's usage counts (--usage) delete the accounts they noted for MCP, the gateway and the pages' logins once 30 days have passed, keeping only counts. In knotless admin stats, an event's accounts are of the days asked, at most the last 30, and a funnel starts with an account that had not done its first step in the 30 days before.

0.1.1 (2026-10-28)

Features

Container images as releases

knotless publish --oci <dir> publishes an OCI image layout as a release, each blob named for its digest, and knotless-serve answers docker pull <host>/<owner>/<repo>/<package>:<version> from those releases at /v2/.

Agents publish and read releases

The MCP tools publish, releases and read_release publish a version of a package, list a repository's releases, and read one file of a release, as knotless publish, releases and download do.

Images can be pushed to knotless-serve's registry, which lists their tags

docker login with the owner's handle and an app password, then docker push to a version's tag, publishes the image as that version's release; tags/list lists an image's versions.

Releases as records

knotless publish publishes a version of a package from a repository, as dev.knotless.release records in its owner's account, never changed once made; knotless releases lists them and knotless download fetches and checks a version's files.

knotless-serve installs from a repository's releases

--releases knotless://<owner>/<name> serves /install.sh and /releases/ from that repository's releases of the knotless package, each file checked against its record and kept, rather than from a directory.

Fixes

Releases stream

knotless publish reads each file a part at a time as it uploads it, and knotless download writes each part as it reads it, beside the file until it is whole and checked, so a file of any size takes only a few parts' memory.

A runner's pass that runs long says where it is

knotless-run logs each pass over a repository as pass ended, with how long it took, and one still going after 5 minutes as pass running long, with the stage it is at, every 5 minutes. A git command slower than KNOTLESS_SLOW_MS is logged at warn, as git. The same failure of a repository is logged once a minute while it goes on, with a count, rather than every time.

knotless-serve's image is published as a release

Each new version's image is the release of the knotless-serve package: docker pull knotless.dev/chadtmiller.com/knotless/knotless-serve.