Releases

What changed in every project, release by release: the notes of the latest five releases of each, the newest first, in the words of their users, as each project writes them into its changelog. A release that came out after this page was built shows up below the heading of its project, with a link to its notes on GitHub. The feed of all releases brings each new one into a feed reader, and the dashboard shows the state of every project.

HomeDarts for Autodarts

HomeDarts v2.0.1

2026-10-23 · Release on GitHub

Fixed

• Ask Assist about your darts sounds more natural in German, Spanish, French and Dutch: the answers use the same words as the rest of the integration, such as "¡Objetivo diario alcanzado!" and "Dagdoel bereikt!", and read as people say them, such as "Alex führt die Bestenliste mit einem 3-Dart-Average von 167 an." or "Vandaag: 3-dart-gemiddelde van 120,2 over 18 darts.". Assist also understands more ways to ask, such as "Was ist mein höchstes Finish?", "Wer steht an der Spitze der Bestenliste?", "¿Cuál es mi mejor checkout?", "¿Cuántos días seguidos llevo entrenando?", "Combien de jours de suite ?" and "Hoeveel dagen achter elkaar?". The update brings the new sentences and answers to every automation made from the blueprint; an automation in which you changed the sentences keeps yours, so add the new ones there yourself.
• The security scans pass again for the test tools of Home Assistant: Home Assistant 2026.10 pins Pillow 12.3.0 and uv 0.12.23 for the tests of every integration, and no update of the tests can fix their advisories until Home Assistant moves on, so the OSV-Scanner and Findings checks failed on every change. osv-scanner.toml now accepts every advisory of exactly these two versions, with the reason and until 2026-11-22. Nothing that you install changes: the integration ships neither of them.
• The training report and Assist speak a regional language of Home Assistant: the ready-made summary of the training report now comes in the language of Home Assistant, such as "30 Darts, 3-Dart-Average 57,3, höchste Aufnahme 140, 1 × 180." in German, from the new summary attribute of the Training darts sensor; an automation made from the blueprint gets it with the update. Assist answers in German, Spanish, French or Dutch also when Home Assistant speaks a regional variant such as de-CH or es-419, with the name of the game in that language too, instead of in English.

Every pull request of this release

Bug fixes

• i18n: review the questions and answers of Ask Assist in German, Spanish, French and Dutch (#455) (a08706f)
• security: accept the advisories of the test tools that Home Assistant pins (#458) (b749968)
• the training report and Assist answer in the regional language (#457) (9870397)

Compare with the previous release

HomeDarts v2.0.0

2026-10-21 · Release on GitHub

Breaking changes

• Autodarts is now HomeDarts for Autodarts: Autodarts asked the project to stop using its name and logo, so the integration has a name and an icon of its own and the domain homedarts. Its actions are now called homedarts.…, such as homedarts.start_game, its cards custom:homedarts-…, its dashboard strategy custom:homedarts, and the flat board style of the live and heatmap cards is flat; highlights, exports and voice packs live in the media folder homedarts. If HACS says No manifest.json file found 'custom_components/autodarts/manifest.json', restart Home Assistant and update again. After the update, add HomeDarts for Autodarts and choose to take over your boards: they keep their entities, history, statistics and dashboards. Automations and scripts that call the old actions need the new names (From Autodarts to HomeDarts).
• No cloud link: Autodarts issues no client IDs to third parties, so the prepared link to the Autodarts cloud is gone, and HomeDarts works locally with the Board Manager. Online matches still reach Home Assistant through Tools for Autodarts.

Improved

• An icon of its own: Home Assistant, HACS and the website show the integration's own icon, a house with a dartboard and a dart in its bull, in place of the Autodarts logo, which Autodarts asked the project to remove.

Every pull request of this release

⚠ BREAKING CHANGES

• HomeDarts for Autodarts, a name of its own (#442)

Features

• an icon of its own in place of the Autodarts logo (#438) (e26c118)
• HomeDarts for Autodarts, a name of its own (#442) (984b834)

Compare with the previous release

HomeDarts v1.18.0

2026-10-19 · Release on GitHub

Fixed

• Voice control finds the darts of the visit by what they show: a dart you can tap to correct now starts its spoken name with the words on its tile, such as "Dart 2 S20 20 points – Correct dart 2" on the Autodarts card and "S20 20 – Correct dart 2" on the scoreboard, so "click S20 20" in Voice Control or Voice Access taps it, and a screen reader no longer runs the bed and the points together.

New

• The Start tournament button chooses the groups and who goes on: two settings join the other tournament settings, Tournament groups (2 to 8, or 0, the default, for groups of about four players) and Tournament qualifiers per group (1 to 4, two by default). Start tournament plays groups and knockout with them, and so does start_tournament when you leave out groups and advance; groups: 0 asks for groups of about four players. The new game screen of the scoreboard starts from them, and the groups you choose there or in the action stay in them for the next tournament (tournaments, #389).

Every pull request of this release

Features

• the Start tournament button can choose the groups and qualifiers (#421) (e080816)

Compare with the previous release

HomeDarts v1.17.0

2026-10-19 · Release on GitHub

New

• Tournaments of up to 32 players, in a double elimination or groups with a knockout: a knockout now takes up to 32 players, with a round of 16 and a round of 32, and two formats join the round robin and the knockout. In a double elimination, nobody is out before losing two matches: a loser of the winners' bracket gets a second chance in the losers' bracket, the winners of both meet in the grand final, and a deciding final follows if the winner of the losers' bracket wins it. With groups and knockout, six to 32 players play a round robin in two to eight groups, of about four players unless you choose the number, and the best of every group, two unless you choose one to four, go on into a knockout, where the group winners are the top seeds and nobody meets a player of their own group in its first round. Choose them on the new game screen, with steppers for the groups and how many of each go on, or with start_tournament (format: double_knockout or groups_knockout, groups, advance). Between the matches, the scoreboard shows the tables of the groups side by side with the places that go on marked, and the losers' bracket below the winners' bracket; brackets of 16 and 32 places get smaller boxes. Tournament players shows as many names as its 255 characters hold, then …, and lists them all in its attribute players. A round robin still takes up to eight players (tournaments, #381, #385).
• One tournament on several boards at once: a club evening with two boards or more plays one tournament on all of them, Autodarts boards and dartboards without Autodarts alike. Start it with start_tournament and the other boards in boards, which the action's device picker fills: every board plays a match of its own at once, and after its pause a board takes the next match whose players play at no other board, as soon as it is clear. The players get their pause too, wherever they played last. The board that started the tournament holds it: the table or the bracket takes the results of every board, and its tournament_match_finished events name the board that played the match. Between the matches, the scoreboard of every board shows a box for each board, with the match it plays or when its next one starts, and the expected end of the tournament, worked out from the players' averages and the pace of the matches played; Tournament has it as ends_at at one board too. Stop tournament on any board stops it on all of them, and the boards find each other again after a restart (a tournament on several boards, #394, #396).
• Random Cricket and Hidden Cricket, as on Scolia, Granboard and Dartsmind: two more Cricket games for one to four players or two teams, also against the bot and in tournaments. Random Cricket plays six numbers of 1 to 20 and the bull, drawn anew for every leg; Hidden Cricket keeps them hidden, as question marks on the chalkboard, until a dart finds one, and then shows it to everybody. Marks, points and the win follow the rules of Cricket. The numbers stay the same through an undone visit and a restart of Home Assistant, the scoreboard's caller names them, and the bot searches for the hidden ones. Start them from the new game screen, by voice or with start_game (Random Cricket, Hidden Cricket, #361, #364).
• The scoreboard in your stream, and clips of your highlights: the automatic dashboard has a Stream overlay view for a browser source in OBS Studio or Streamlabs, at its address with /overlay at its end, which its tabs leave out. It shows the scoreboard alone over the picture of your stream: the game, every player's score, the checkout route, the darts of the visit, the winner and the confetti, on dark plates that stay readable over any video, and nothing between games. It is see-through along the bottom of the picture; the dashboard's settings and the card's options overlay, overlay_layout and overlay_color put it in the top-left corner or across the whole picture, or on a key colour for the chroma key filter of OBS, #00FF00 unless you choose another. On a dashboard the overlay fills the window and hides Home Assistant around it, and Escape or a double click leaves it. With a Clip camera, a camera of the room or of your stream, the highlight photo also records every big moment as an MP4 beside its photo, from a few seconds before the dart, and the highlight gallery plays it; the recording runs in the background, so your notification goes out at once (stream overlay, highlight clips, #370, #372).
• Ask Assist about your darts: the new blueprint Autodarts: ask Assist about your darts answers "What is my average today?", "How many 180s this week?", "How many darts today?", "What is my best checkout?", "How long is my streak?", "Who leads the leaderboard?" and "Where should Sam aim?" in English, German, Spanish, French and Dutch, for example "Wie ist mein Schnitt heute?", "¿Cuántos 180 llevo esta semana?" or "Où dois-je viser ?". Assist answers from the statistics of the board in the language you asked in, such as "Today: a 3-dart average of 120.2 from 18 darts.", or says what is missing before the first dart. Today counts every training session that started today, the week is that of the weekly report, the leaderboard ranks as the scoreboard does, and "Where should I aim?" is for the player linked to the person you are signed in as. With more than one board, the board with the most darts this week answers unless you choose one. Like every blueprint, it now comes with the integration (ask Assist about your darts, #376, #378).
• The blueprints come with the integration and stay current: after installing the integration, all fifteen blueprints are on the blueprints page of Home Assistant without importing them. Every update brings the new versions of the blueprints you haven't changed, also of those you imported before, and the automations made from them reload with their settings, so a blueprint always matches the integration it runs with. A blueprint you changed stays yours, with a repair that offers the version of the integration; one you deleted stays deleted, and Re-import blueprint is no longer needed (updates of the blueprints, #383, #384).
• Granboard over Bluetooth (experimental): a Granboard sends its darts to Home Assistant over Bluetooth, through an adapter of Home Assistant or an ESPHome Bluetooth proxy anywhere in the house, and you play every game, the training and the statistics with them, as on a dartboard without Autodarts, without entering a dart. Home Assistant finds the board and offers to set it up; every hit goes into the visit, the button beside the board passes to the next player, a dart in the wrong bed is corrected on the scoreboard, and a board that sleeps or goes out of reach connects again on its own. The diagnostic entity Granboard connection shows the connection. The integration reads the board's frames as open-source Granboard apps do, but it has not met a real board yet: check every bed with yours to help take the label off (Granboard over Bluetooth, #386, #388).

Every pull request of this release

Features

• a streaming overlay for OBS and highlight clips (#372) (39c4903)
• blueprints: ship the blueprints with the integration and keep unedited copies current (#384) (e2ce8aa)
• cricket: Random and Hidden Cricket (#364) (e7f1d0c)
• Granboard dartboards over Home Assistant's Bluetooth (experimental) (#388) (c878223)
• tournament: play a tournament on several boards at once (#396) (4f009ae)
• tournament: up to 32 players, groups with knockout and double elimination (#385) (4b6e33b)
• voice: ask Assist about your darts (#378) (37fb3c3)

Compare with the previous release

HomeDarts v1.16.0

2026-10-18 · Release on GitHub

New

• The score on a pixel display at the board: the new blueprint Autodarts: score display shows the practice game on an AWTRIX 3, such as the Ulanzi TC001, or on a PixelIt: the score of the player at the board after every dart, in green with its route when a checkout is possible, the points in Cricket and the party games, and for a few seconds a 180, a bust, a won leg and the winner of the match. When the game is switched off, or after the idle time, the display goes back to its clock. AWTRIX 3 and PixelIt take the screen over MQTT, and PixelIt also over HTTP through a REST command (score display, #343, #346).
• The scoreboard on a TV through Chromecast: Home Assistant Cast shows the cards and the automatic dashboard on a TV with a Chromecast or on a Google Nest Hub, where it said Custom element doesn't exist before. The integration keeps its two modules in the dashboard resources, which Cast loads, brings them up to date with every start of Home Assistant and removes them with its last board; browsers still load them once. With resources in YAML, add the two lines that the documentation names. The pictures of the players come from the address of Home Assistant, so they show on the TV too (Home Assistant Cast, #347, #349).
• The callers and the weekly report speak your language: freshly imported, the dart caller, the practice caller and the weekly report speak the language of Home Assistant, in English, German, Dutch, French and Spanish, without a message of your own. In German, for example, the practice caller says "Lea, du brauchst 101", "Überworfen" and "Game shot, und das Match, Lea!", the dart caller "Einhundertachtzig!" and "Triple 20", and the weekly report arrives as Deine Dartwoche with a decimal comma. They follow a new language of Home Assistant at once. The board events bring these words in call, and the weekly report in title and summary, for your own automations too. In English, every call stays as it was, and messages you wrote yourself stay as they are; Word for the bot and Word for a player without a name now only apply to those. Pick a voice that speaks the language of Home Assistant, and to keep English calls in a Home Assistant of another language, enter the English examples as your messages. An automation you set up before speaks your language once you re-import its blueprint; if it saved the English default of before, replace that with {{ call }} (calls in the language of Home Assistant, #352, #353).
• A caller for blind and low-vision players: the caller of the scoreboard can call every dart as it lands, by its bed, such as "Treble 20", or by its points, such as "60"; the route of a checkout, such as "Treble 19, Double 12", and again after each dart that leaves another finish for the darts left; and the next target of a training or party game, such as "Target: Double 16", as soon as it moves on. Switch on Call every dart, Call the checkout route and Call the next target in the caller options of the scoreboard or in the settings of the automatic dashboard; they are off until you do. With a voice pack, the darts, routes and targets play its files of the beds as darts-caller names them, bs_target_is and bs_any_double included, which Generate voice pack now records too, and the browser's voice says what the pack lacks (for blind and low-vision players, #358, #360).
• Online matches from the Autodarts cloud, once it is linked: the integration is ready for the cloud link, which waits for the client ID that Autodarts issues to the integration. Once linked, the busts, won legs and matches and every dart of your online matches arrive as the same board events as from the online bridge (the cloud link), with the source cloud, without a browser with Tools for Autodarts, and a board without a Board Manager in your network, such as Lens, gets the Events entity for them. While the bridge is switched on, it alone reports them. A linked board renews its login a minute before it expires, as Autodarts advises (#365).

Improved

• Quicker on a Raspberry Pi: every action, such as a button, a setting or a new game, built the whole store of the training twice: once to save it and once more to compare it with what it had saved, which with a long history and many players took about 20 milliseconds on a desktop PC and several times as long on a Raspberry Pi. It now builds it once, and a dart that lands while it is saved is still saved when Home Assistant stops, as before. The setup hint of the scoreboard and the aim of the bot no longer try 12,341 ways to throw three darts where nothing can be set up, such as 501 at the start of a leg: every setup from 171 to 1001 is found in a tenth of the time, with the same result. Home Assistant also loads the integration about a quarter to half a second faster, because the checkout training no longer works out its 162 scores at every start (setup hints, #329, #333).

Every pull request of this release

Features

• blueprints: callers and reports speak the language of Home Assistant out of the box (#353) (4bb2187)
• blueprints: show the score on an AWTRIX or PixelIt display (#346) (4636838)
• caller: per-dart, route and target calls for blind and low-vision players (#360) (dfcde0d)
• cards: show the cards and the automatic dashboard on Home Assistant Cast (#349) (cc920c8)
• cloud: get the cloud link ready for Autodarts' device login (#365) (e20fc81)

Performance

• faster button presses and bot turns on a Raspberry Pi (#333) (d1f8b3a)

Compare with the previous release

All releases of HomeDarts on GitHub

Player Switch for Autodarts

Player Switch v0.2.0

2026-10-15 · Release on GitHub

• Each release now reaches the Chrome Web Store on its own: the release workflow uploads it and submits it for review, and Google publishes it once the review passes.

Every pull request of this release

Features

• ci: publish each release to the Chrome Web Store (#9) (3fb0bf5)

Compare with the previous release

Player Switch v0.1.1

2026-10-15 · Release on GitHub

• The password form and the account menu no longer show all the time: they appear only under "Manage accounts" and only after a tap on "Remember password".
• An account without a picture at Autodarts shows its initial instead of an empty circle, the popup carries the browser's language, and the labels read "Remember password" / "Stop remembering" and "Remove account".

Every pull request of this release

Bug fixes

• popup: hide the password form and account menu until asked for (#4) (84ffac1)

Compare with the previous release

Player Switch v0.1.0

2026-10-15 · Release on GitHub

• Switch between saved Autodarts accounts on a shared display with one tap: the extension parks each account's session, keeps parked sessions fresh in the background, and can optionally remember a password to sign an account back in.
• A redesigned popup: a clean tile grid of players with a separate "Manage accounts" mode, and German and English throughout.
• Clearer messages when a switch can't happen (no Autodarts tab, Autodarts unreachable, or an account that must sign in again).
• A renewed token is now saved before it is written into the page, so a page that reloads or closes mid-switch can no longer lose a session.
• Ready for the Chrome Web Store: scripts/package-extension.sh builds the upload zip, the manifest version follows the release, and there is a privacy policy and listing texts.

Every pull request of this release

Features

• switch between Autodarts accounts from the extension (#1) (6dc51ef)

All releases of Player Switch on GitHub

Paperless Sync

Paperless Sync v1.2.0

2026-10-23 · Release on GitHub

Features

• Help in German for a German Nextcloud: the Help links of the settings and the links of the warnings of Paperless Sync in Administration → Overview open the German guide on the website when Nextcloud speaks German to you, and the English one in every other language. The German README and the German pages of the website show the app in German pictures, and the German README links to the German website, its FAQ and its troubleshooting.
• Lighter previews in the App Store: each screenshot of Paperless Sync in the Nextcloud App Store comes with a small thumbnail, which the list of the apps loads in place of the whole picture. Every release points both at its own version.
• The errors of a run in the language of the administrator: the status and the report on the settings page now show the errors that Paperless Sync explains in the language of the administrator who reads them, such as Den Nextcloud-Benutzer paperless gibt es nicht. or a full quota, also for a scheduled run, which has no reader when it fails. The log, occ paperless_sync:run, occ paperless_sync:status and the status API keep them in English, and the messages of Paperless and Nextcloud within an error stay as the run got them. The status of a run before the update still shows, in English, until the next run.

Bug fixes

• The report of a dry-run stays in view: an answer of the status that the settings page asked for before a dry-run, such as the one after Save, could arrive after the report of the dry-run and show the report from before it again, such as Dry-run, finished in place of Dry-run of unsaved settings, finished. The page now shows only a status that is newer than what it shows, and keeps following a run that is queued or active.
• Every deleted copy goes to the trash bin of its user: a copy that a run deleted, such as one of a document with an excluded tag, one in the deleted folder after Paperless deleted its document for good, an inbox file after its import or an emptied folder, went to the trash bin of the target user only when the run set up the files of that user first. With per-user ownership, the copies that left the archive of any other user, such as for a new owner, were gone for good, and so was a deletion in a process that had set up the files of another user, such as of an administrator. Every run now changes the files of each user in that user's own files, so every deletion lands in Deleted files of its user, whoever or whatever starts the run. The switch of permanent deletion in 5 · Trash and deletion safety is now called Delete the Nextcloud copy after Paperless deletes the document for good.

Every pull request of this release

Features

• App Store screenshots get a small thumbnail (#242) (7f8c507)
• l10n: German screenshots, German website links and a German help link (#246) (073dfcd)
• translate the errors of a run in the status and the report (#245) (a1aa889)

Bug fixes

• every deleted copy goes to the trash bin of its user (#244) (a79c319)
• settings: keep the report of a dry-run when an older status arrives late (#237) (56e9e4b)

Compare with the previous release

Paperless Sync v1.1.1

2026-10-20 · Release on GitHub

Bug fixes

• A document that Paperless still has keeps its copy, also when a scan left it out: when one document was deleted in Paperless and another one added while a run read the pages of its list, the count of Paperless stayed the same, and a third document that still exists could be left out without a sign. That counted as a missing scan, and with Required consecutive missing scans at 1 its copy moved to the deleted folder, or was deleted with direct deletion. A run now asks Paperless for each document that a scan would count as missing: only when Paperless answers that it has no such document does the scan count; a document that Paperless still has keeps its copy and starts its count anew, and an error of Paperless counts nothing in that run and shows in the report. A run asks at most twice as many of these questions as Maximum changes per module and run allows, and none after the first error, so a run stays short also when many documents vanish at once.

Every pull request of this release

Bug fixes

• ask Paperless before counting a document a complete scan left out as missing (#229) (b0faab3)

Compare with the previous release

Paperless Sync v1.1.0

2026-10-19 · Release on GitHub

Fixed

• Screen readers name the custom field button as it reads: the button custom_fields.… under the path template now announces its visible text, with Insert a custom field, then type its name as its tooltip and description, so voice control finds it by what it shows.

Features

• Every user their own documents: with Who gets the documents in 1 · Connection and ownership set to Each user, those they own in Paperless, each user of Nextcloud gets the documents that their user of Paperless owns, in the same folders below the base folder of their own files: by the same ID, whatever its case, as single sign-on such as OpenID Connect gives them, or by the table Paperless users with another Nextcloud ID, and only for the members of a group if you choose one. The files of a user's inbox, and those they send with Send to Paperless or a rule of Flow, become theirs in Paperless and come back into their archive. The target user gets the documents without an owner and those of users of Paperless without a user of Nextcloud, so that none is lost; the documents of two users of Paperless for one user of Nextcloud stay where they are until each has a user of their own, and the connection checklist shows who gets which documents, with their numbers. When the owner of a document changes in Paperless, its copy moves to the archive of the new owner. Each user has their own batch, Activity entries and notifications, and the report and the status API count the changes of each user. The account of the app needs to see the documents of every user and to view the users of Paperless; the security design explains how. The default, the target user for all documents, keeps your archive as it is (#84).

Bug fixes

• The real reason of a failed import on Paperless-ngx 2.x: Paperless-ngx 2.x marks a failed import first without its reason, as <traceback object at 0x…>, and writes the reason a moment later. A run that checked the import in that moment moved the file to the error folder with the placeholder in its .error.txt, and a file sent from Files reported it in its notification. The app now waits for the reason, so the .error.txt and the notification say why Paperless didn't import the file.

Every pull request of this release

Features

• give every Nextcloud user the Paperless documents they own (#230) (db6809f)

Bug fixes

• a 2.x task that just failed reports its real error, not the traceback placeholder (#227) (4df72ac)

Compare with the previous release

Paperless Sync v1.0.0

2026-10-18 · Release on GitHub

Features

• Send to Paperless and Open in Paperless in Files: the menu of a file or a folder in Files, and of a selection, has Send to Paperless: the file goes to Paperless with the tags of the inbox, those of its subfolders below a sent folder included, and stays where it is, and a notification tells you when Paperless has it, with a link to the new document, or why Paperless didn't import it. A file whose content Paperless has already isn't uploaded again, so Paperless-ngx 3.x makes no duplicate. The uploads use the API token of the app, so only the members of Group that may send files in 4 · Nextcloud inbox get the action: the administrators, until you choose another group or none; the connection checklist then tests that the account of Paperless may add documents, as a warning while the inbox is off, so a mirror whose token may not upload keeps a clean checklist (empty the group to turn the action off). Files of a share whose owner allows viewing only can't be sent, because a copy in Paperless would be a download. Open in Paperless opens the document of every copy of the archive, by the marker such as [P123] in its name, for everyone who sees the file.
• Send to Paperless in Flow: administrators can make rules in Administration → Flow that send files to Paperless on their own, such as every PDF that a member of a group uploads, or every file of a folder that has the tag To Paperless: the file goes to Paperless with the tags for every import of the inbox and the tags of the rule, which the form of the rule suggests from Paperless, and stays where it is. The uploads use the API token of the app, so only administrators can make such rules; the files of the folder of the app, which a run writes, and copies of the archive stay out. A rule may send many files, so the owner of a file hears only of an import that Paperless refused or that failed.
• Metadata next to the archive: with Write metadata next to the archive in 3 · Structured archive, every run writes what Paperless knows of each document into the hidden folder .paperless of the archive: P123.json with the title, the correspondent, the document type, the tags, the notes, the custom fields, the dates and the address in Paperless, and index.csv with a row for every document and the path of its copy, which LibreOffice Calc opens with a double-click and Excel with Data → From Text/CSV. So the archive describes itself also without Paperless, such as in a backup of Nextcloud or on the way to another system. A sidecar is written only when its content changes, at most as many in a run as its batch size allows; its row follows its copy into the deleted folder, and the sidecar goes with the copy under the rules of deletion safety. Everyone who can open the archive folder can read the notes and custom fields there, so check its shares first. It is off until you turn it on.
• Tags in Nextcloud: with Show Paperless tags as Nextcloud tags in 3 · Structured archive, each copy carries the tags of its document as collaborative tags of Nextcloud, so that Files filters and searches the archive by them. They follow every change in Paperless, also of a document whose copy stays as it is, every user sees them, and only administrators can assign them; a tag that someone made in Nextcloud stays as it is, and the report names a tag of Paperless whose name such a tag has already.
• Only mirror documents with these tags: a new field in 3 · Structured archive turns the archive into a mirror of a part of Paperless, such as only the documents tagged Nextcloud. A document needs at least one of the tags, whatever the case of its name; an excluded tag and the inbox of Paperless still leave a document out. A document that loses its last tag to mirror loses its copy in the next run, within the batch size, as one with an excluded tag does, and the preview under the path template and a dry-run show which documents a new list leaves out before you save it. Every tag to mirror must be a tag of Paperless: a typo or a tag renamed in Paperless stops the export before a file changes, and says which name is missing, instead of removing the copies of the documents that should stay. Empty, as it is by default, the archive mirrors every document as before.

Changed

• The first stable version, 1.0.0. The app now does what it was built for: it mirrors Paperless-ngx into Nextcloud Files as an archive by correspondent, type and year that keeps the shares, comments and versions of its files and moves a copy into the deleted folder only when Paperless has confirmed its document gone, sends the files of an inbox folder, of the menu of Files and of Flow rules to Paperless, follows the changes of Paperless within seconds through its workflow webhook, and tells how each run went in the settings, in the Activity stream, in notifications, in the setup checks of Nextcloud, with occ and through its status API, documented for administrators from the installation to the troubleshooting. From now on, a release that asks more of your server, such as a newer Nextcloud, PHP or Paperless-ngx, or that changes the path template variables, the occ commands of the app or its status API in a way that breaks your archive, a script or a monitor, is a new major version, so that an update within 1.x never needs more than the update itself.

Bug fixes

• One Paperless for the whole run: settings that you save while a run is busy, such as the connection to another Paperless, apply from the next run. Before, the rest of the run could reach the new Paperless and record its documents as those of the old one, or stop part-way. A run also reads the API token from Nextcloud's credentials store once, instead of twice for every request to Paperless.

Every pull request of this release

Features

• archive: optional metadata sidecars and an index next to the archive (#191) (fd9ceca)
• archive: optionally mirror only documents with chosen tags (#198) (a1d37c8)
• archive: show Paperless tags as Nextcloud tags on the mirrored files (#200) (d473bbd)
• files: 'Send to Paperless' and 'Open in Paperless' file actions (#194) (0657861)
• Nextcloud Flow operation 'Send to Paperless' (#197) (9c31ea2)

Bug fixes

• one Paperless connection per run through a client factory (#185) (b2a1879)

Documentation

• release the app as 1.0.0, its first stable version (#202) (a2b71dd)

Compare with the previous release

Paperless Sync v0.4.0

2026-10-17 · Release on GitHub

Features

• Files of the inbox can bring their tags to Paperless. With Subfolders become tags, a file in Inbox/Taxes/2026 gets the tags Taxes and 2026, as the consume folder of Paperless does with PAPERLESS_CONSUMER_SUBDIRS_AS_TAGS, and Tags for every import go with every file. A name finds the tag of Paperless whatever its case. A name that Paperless shows the account of the app no tag of is named once in the report of the run and in the Nextcloud log, and the file goes without it; with Create missing tags, the run creates the tag instead, without a match, so that Paperless assigns it to no other document, and without an owner, so that every account that may view tags sees it. The report names the tags of each file, a dry-run shows the tags that a run would create, and Test connection checks the permissions View and Add for Tags that the tags need. All of it is off until you turn it on.
• Synchronize now queues the run as a background job of Nextcloud and answers at once, so a reverse proxy no longer cuts off a long run and shows its own error page. The status says Queued until the background jobs start the run, within five minutes with the system cron or at once with occ background-job:worker --once 'OCA\PaperlessSync\Cron\ManualSyncJob', and the page follows it and then says how it ended. Like a scheduled run, it keeps the previous content of an updated copy as a version. While a dry-run or another run is active, it waits for the next background jobs.
• Command line: occ paperless_sync:run runs a synchronization or, with --dry-run, lists its changes, in the shell and as long as it takes; --batch-size=N or --unlimited changes the batch size for this run, such as for the first import of a large archive. occ paperless_sync:status shows the status of the last run, and occ paperless_sync:forget <ID>… or --all makes the next runs download documents again and write each in place of its copy. Every command prints text or, with --output=json, JSON, and tells by its exit code how it ended: 0 completed, 1 with errors of single documents, 2 failed, 3 another run is active.
• A run that ended without saying how, because PHP stopped it, such as on a restart of the server, shows as Interrupted instead of Running forever, once its lock is gone and it gave no sign of life for 15 minutes. A run that takes longer than Nextcloud keeps its lock, an hour by default, writes a sign of life every minute, so no scheduled run or Synchronize now starts beside it.
• The settings offer the users of Nextcloud for the target user, and the tags of Paperless for the excluded tags and the tags for every import, so that you pick them instead of typing them. A user ID that Nextcloud doesn't know is marked as soon as you leave the field, a disabled account says disabled, and a tag that Paperless doesn't have is marked not in Paperless, so a typo shows before a run instead of as documents that are exported anyway or imports without their tag. A tag that Paperless doesn't have yet can still be typed, ended with Enter or a comma. The tags come from Paperless with the saved URL and token, which stays on the server.
• The report of a run reads in your language instead of a block of English codes: every change has a colored badge of its kind, such as Export, Trash or Refused, with its document, its file and what happens to it; the errors come first, then the notices, such as an incomplete scan of Paperless; a filter above the list shows the changes of one kind. Only the counts of changes that happened show, and a sentence such as 11 unchanged, 1 skipped the rest; a dry-run says Dry-run — nothing was changed in its heading. When you are the target user, a click on the path of a file opens its folder in Files, and Copy report copies the report, with its lines in English, for a bug report.
• Changes within seconds: a workflow of Paperless can call the webhook of the app when it adds or changes a document, and the copy of that document is exported, moved or removed within seconds instead of with the next scheduled run, by the same rules as a run. Section 6 of the settings creates its secret, which only Paperless needs, shows the webhook URL and the last call, and lists the steps in Paperless; calls without the secret are refused and slowed down by Nextcloud.

Every pull request of this release

Features

• inbox: subfolders as tags, tags for every import and missing tags created (#170) (b0b9dc4)
• near-real-time sync through a Paperless workflow webhook (#179) (ce4df11)
• occ commands and 'Synchronize now' as a background job (#171) (641decc)
• settings: a readable, translated run report (#176) (d91b0ea)
• settings: user and tag pickers instead of free-text fields (#178) (10b70e6)

Compare with the previous release

All releases of Paperless Sync on GitHub

Paperless Unified Search

Paperless Unified Search v1.1.1

2026-10-19 · Release on GitHub

Bug fixes

• The archive account of Paperless Sync 0.3: with no archive account of its own, the app takes the account that Paperless Sync writes the archive with again. Paperless Sync 0.3.0 stores it in a way that the app didn't read, so the search showed no Paperless documents at all, and the settings, occ and the overview said that Paperless Sync names no account.

Every pull request of this release

Bug fixes

• find the archive account of Paperless Sync 0.3, which stores it lazily (#168) (b279db2)

Compare with the previous release

Paperless Unified Search v1.1.0

2026-10-17 · Release on GitHub

Features

• Dashboard: the widget New in Paperless lists the newest Paperless documents that you can open, each with the preview of its file, the day that Paperless added it, its correspondent and its type, and opens a document's file in Files. Paperless gets one request a minute for the dashboards of all users.
• Try it in three minutes: bash demo/seed.sh starts a real Paperless-ngx and a real Nextcloud in Docker on your own machine, gives Paperless five synthetic documents, sets up Paperless Sync and this app, and ends with a search that finds the documents, so you can see the app at work without touching your own servers. demo/README.md says what to try.

Every pull request of this release

Features

• a dashboard widget with the latest Paperless documents (#172) (b463f15)
• a one-command demo with real Paperless-ngx and Nextcloud (#165) (882652e)

Compare with the previous release

Paperless Unified Search v1.0.1

2026-10-17 · Release on GitHub

Fixed

• The checks before a push no longer commit into the repository that runs them. bash scripts/check.sh tests the scripts of the end-to-end tests in throwaway Git repositories. When GIT_DIR was set, as Git sets it for the hook before a push in a worktree and as an agent sets it for a worktree in a container, those tests made their commits in the repository that ran them instead: git init rewrote its configuration, such as core.filemode, and its branch got a commit "The base branch" by E2E <e2e@example.com>. Now the tests clear these variables of Git before their first git, and scripts/check-project.sh runs them with GIT_DIR set to a repository of their own and fails if they change its commits, branches, configuration or checkout.

Every pull request of this release

Bug fixes

• test: keep the selftest of the end-to-end scripts out of the repository that runs it (#159) (a3138fc)

Compare with the previous release

Paperless Unified Search v1.0.0

2026-10-14 · Release on GitHub

Added

• Search results show a preview of the document, its date in your language, its correspondent and its type. Every Paperless result had the same icon of the app and its date as Paperless writes it, such as 2026-08-12, so documents were hard to tell apart at a glance. Now each result shows the preview of its file, or the icon of its type, as the results of Files do, and below its title the date in your language, such as Aug 12, 2026 or 12.08.2026, the correspondent and the type of the document, and the words around your term. A search that found the term only in a note, such as notes:transfer, shows the words of the note. The names of correspondents and types cost one request to Paperless per kind and are kept for ten minutes; the account of the API token needs the permission to view them, and without it the results show without the names. Text of a document in angle brackets, such as <GmbH>, now shows as < GmbH>, so that no part of a result can act as HTML.
• Set up and test the app with occ, see its health in the administration overview, and ask occ why a document doesn't show for a user. Ansible, Docker and other scripts now connect the app without a browser: occ paperless_unified_search:setup --url=… --token-stdin tests the connection and saves the settings as Test connection and save does, and takes the API token from the standard input or an environment variable, never from the command line. occ paperless_unified_search:test tests the connection for monitoring, and occ paperless_unified_search:check also checks the archive account and counts how many Paperless documents have a file, such as 1,180 of 1,234. When a user doesn't find a document that Paperless finds, occ paperless_unified_search:search jamie invoice --explain names the reason for each one: its file isn't shared with jamie, it belongs to another account, or no file has its marker yet. And Administration settings → Overview now warns when the search shows no Paperless documents, for a token that can't be decrypted, a missing archive account or a search that keeps failing, with a link to the settings of the app.
• The date filter of Nextcloud's search now narrows Paperless results by document date. Picking a span such as Last 30 days or a custom range in Nextcloud's search left the Paperless results out of the filtered list, under Partial matches and searched without the dates, so an invoice of last month could not be told from all the others. Now Paperless finds only the documents whose date lies within the span, counted in whole days in your timezone, and the results stay in the filtered list. Scripts and AI assistants that use Nextcloud's search API narrow the results the same way with since and until.
• Try a search in the settings shows why a Paperless document is or isn't shown to a user. Administrators of a managed Nextcloud without a shell could not answer the most common question, "why don't I see this document?": the search leaves out a document without a file that the user can open, without a trace. Now Try a search at the end of Administration settings → Paperless Unified Search searches Paperless as the user you name and lists the first 20 documents with their IDs and titles, each shown or with its reason: not shared with the user, not a file of the archive account, or no file with its marker such as [P412], the same answers as occ paperless_unified_search:search --explain. It shows the titles alone, never the content or the files of the documents, and the audit log of the app Auditing / Logging (admin_audit) records which administrator tried a search as which user, whatever the log level.

Changed

• The app asks Paperless for version 9 of its API, and needs Paperless-ngx 2.16 or newer. So far, the app took whatever version of its API Paperless answered in by default, which a new release of Paperless raises, as Paperless-ngx 3 did, and a new version may change what a field holds, as version 9 did with the date of a document. Now every request names version 9, which Paperless-ngx 2.16 and newer and every Paperless-ngx 3 speak, so a new release of Paperless can no longer change the results unnoticed: tests against real Paperless-ngx 2.20 and 3.x check every week and with every new release of Paperless that the fields, dates and excerpts of the search stay as the app reads them. A Paperless older than 2.16 answers HTTP 406; Test connection and save and occ paperless_unified_search:test then say that Paperless is older than 2.16 and that updating Paperless-ngx fixes it.
• The first stable version, 1.0.0. The app now does what it was built for: the full-text search of Paperless-ngx in the search of Nextcloud and in its smart picker, narrowed by the date filter, with a preview, the date, the correspondent and the type of each document, set up and explained with occ and with Try a search in the settings, and documented for administrators from the installation to the troubleshooting. From now on, a release that asks more of your server, such as a newer Nextcloud, PHP or Paperless-ngx, or that changes the occ commands of the app in a way that breaks a script, is a new major version, so that an update within 1.x never needs more than the update itself.

Fixed

• A search that is still being typed in Paperless's advanced syntax finds the documents of its words in Paperless 3. Since 0.5.1, Paperless 3 gets such a search, such as invoice created:[2026 to, in its simple mode, but with the unfinished range of dates, which no document matches, so it found nothing, as tests against a real Paperless-ngx 3.3 showed. Now the simple mode gets only the plain words, such as invoice, and finds their documents while you finish typing the range.

Every pull request of this release

⚠ BREAKING CHANGES

• ask Paperless for version 9 of its API and test against real Paperless-ngx 2.20 and 3.x (#147)

Features

• ask Paperless for version 9 of its API and test against real Paperless-ngx 2.20 and 3.x (#147) (ce8798e)
• occ commands to set up, test and explain the search, and a setup check in the overview (#138) (4c135ed)
• search: let Nextcloud's date filter narrow Paperless results (#154) (ca9c1e6)
• search: show a preview, the date in the user's language, the correspondent and the type of each document (#143) (6225a8a)
• settings: 'Try a search' shows administrators why a document is hidden from a user (#152) (6f62d38)

Documentation

• release the app as 1.0.0, its first stable version (#156) (7de8969)

Compare with the previous release

Paperless Unified Search v0.5.1

2026-10-14 · Release on GitHub

Fixed

• A search that is still being typed in Paperless's advanced syntax no longer shows as a failed search, and a Paperless that hangs no longer makes every search wait twice. Paperless 3 refuses a query that it can't parse yet, such as created:[2026 to while you type the range of dates, and the search showed nothing for it while Search problems in the settings filled up with failed searches that were none, pushing real problems out of the list. Now such a search finds the documents of its words in the simple search of Paperless 3, and neither it nor a page past the last result shows up as a problem. A request that waited in vain for a Paperless that accepts connections but doesn't answer, as while it consumes documents or rebuilds its index, was sent a second time, so every keystroke waited 20 seconds and Paperless got every request twice; now only a request that never reached Paperless is tried again. During an outage, also one that comes and goes, Search problems notes a failure at most once in 30 seconds, with every problem still counted; a search term with letters such as ä is now left out of its messages also where they are capitals, such as Ä; and the requests tell Paperless and its proxies the real version of the app instead of 0.1.
• The test of the connection says what went wrong, in your language. Saving the settings answered every failure with the same English sentence, "Could not connect to Paperless. Check the URL, API token, and Nextcloud outbound connection policy.", and logged nothing, whether Paperless refused the token, the path was wrong, the host didn't resolve, Nextcloud refused a local address or didn't trust the certificate. Now the message names the cause and what to correct, such as a refused token, a wrong address, a blocked local address or an untrusted certificate, and the log of Nextcloud has the error, without the token. Every message of the settings is now translated, and the app speaks formal German to accounts set to Deutsch (Förmlich: Sie), which saw it in English so far; its description on the Apps page no longer addresses them informally either.
• The settings page shows clear, coloured feedback, keeps Disconnect off until something is configured, and works on phones. In maintenance mode, as during every upgrade, or behind a proxy whose Nextcloud didn't answer, saving showed the whole HTML page of the error as its message, and a lost connection showed "Failed to fetch". Now each of them, and an expired session, gets one short sentence in your language. A failed first save no longer turns on Disconnect, which then wiped the URL you had typed, and after a save the URL field shows the URL as it was stored. Success and error messages have their colours in the light and the dark theme again, which Nextcloud's grey had covered, and an icon, so that they don't rest on colour alone. All fields are equally wide, each checkbox stands in front of its label, the problems of the search are readable cards on a phone, the icon of the section no longer turns pink when it is active, and screen readers read the hints of the token and of Always include Paperless in global search with their fields.

Every pull request of this release

Bug fixes

• l10n: describe the app in German without addressing the reader as du (#140) (6d5f965)
• search: keep typing errors out of the problem history and stop doubling waits on a hanging Paperless (#133) (ed48422)
• settings: name the cause of a failed connection test and translate every message (#124) (1e984d2)
• settings: reliable feedback, a layout that works on phones, and tests for the settings page (#134) (94e149a)

Compare with the previous release

All releases of Paperless Unified Search on GitHub

Issue assistant

Issue assistant v1.6.1

2026-10-19 · Release on GitHub

Fixed

• The Labels workflow no longer fails when another workflow created a label a moment before, such as the settings bot of Repo Blueprint, which the same push starts when it changes .github/labels.toml, as the first push of a new repository always does. sync-labels then gives the label the color and the description of labels.toml, as any label that exists, and /assistant mute does the same for its label.

Every pull request of this release

Bug fixes

• sync-labels accepts a label another workflow just created (#162) (88e7af1)

Compare with the previous release

Issue assistant v1.6.0

2026-10-19 · Release on GitHub

Added

• Updates without install. The four workflows that install writes are short now: what starts them, the permissions that their jobs need at most, and one pin of a reusable workflow of the issue assistant, which has the jobs and runs the action of the same release. A release reaches your repository as a pull request of Dependabot or Renovate that moves the pins, and only a release that changes a template needs install again. Run install of this release once, as step 1 of the set-up shows; your secret, variables and firewall policy stay as they are. .github/actionlint.yaml no longer needs the runner ubuntu-24.04-firewall, which is now in the reusable workflow.
• The assistant learns from your corrections. Every first analysis reads what the maintainers corrected of the analyses of the 30 issues analyzed last: the labels you removed or added, the duplicate notices that someone objected to, and the analyses that one of you gave a 👎, and the AI avoids those choices on an issue like them. GitHub keeps all of it, so correcting the issue is all it takes. The AI gets the corrections as data, one line per issue with its number, title and labels; reading them costs one call to GitHub for each issue and a few more, and [context] max_analyzed in config.toml sets the number of issues, 0 none.
• Three more engines next to Claude: Codex by OpenAI, Gemini by Google and Copilot by GitHub. Set name under [engine] in config.toml to codex, gemini or copilot, and put its secret into the environment issue-assistant: OPENAI_API_KEY, GEMINI_API_KEY or COPILOT_GITHUB_TOKEN, a fine-grained token with the permission Copilot Requests alone and no access to repositories. Gemini starts for free, within the daily limits of the free tier of the Gemini API. Each engine only reads: Codex in the read-only sandbox of its action, and the Gemini CLI and the Copilot CLI, which the action installs and runs itself, with only their tools that read files and without the job's token of GitHub. install writes the hosts of your engine alone into a new .github/egress-firewall.yaml, check names each host that your engine needs and your policy lacks, and the notice to reporters names the engine and its vendor. apply now also takes an answer with a sentence before or after its JSON. Run install of this release once: the workflow issue-assistant.yml passes the secrets of the new engines.
• Priorities, owners of areas and issue types, each when you want them, in .github/labels.toml. With labels of the new group priority, such as priority: high, the AI gives an issue without a priority the one whose description fits, with its reason on the timeline, and never changes one that the issue has or adds back one that someone removed; a possible security report gets none. owners = ["login"] of an area assigns those people to a new issue of the area that nobody is assigned to: when its form chose the area, and after the first analysis; GitHub notifies them, and no comment mentions them; an issue that someone unassigned anyone from stays as it is. issue_type = "Bug" of a kind gives its issues that issue type of your organization, and the type follows the kind while an issue needs triage, to none for a kind without a type; a type that no kind has, such as Epic, stays. check makes sure of their spelling, and the Labels workflow warns of an owner whom GitHub can't assign and of an issue type that the repository doesn't have. Without them, nothing changes.
• Measure how accurate the assistant is in your repository before you switch it on. evaluate replays the first analysis of the closed issues that your maintainers labelled after they were opened or closed as a duplicate, 50 unless --issues asks for another number, each as it was a minute after it was opened, with the engine's command line on your computer, logged in as you, and writes a Markdown report: the precision and recall of the types, areas, topics and priorities, of the duplicates and of the questions for more information, and a line for each issue. It writes nothing on GitHub. The new page How accurate is it? explains the numbers and will have those of the repositories that use the assistant.
• Related issues from sibling repositories. Name up to 5 public repositories that share your users, such as an app and its server, in [related] repositories of config.toml, and every first analysis searches their issues too, links those that help under Related once it checked that they exist, and says in one sentence when an issue may belong in one of them, which the summary of the run names as well. Nothing moves or closes on its own: you transfer the issue by hand, and an issue of another repository is never a duplicate. A repository that isn't public is left out with a warning, since its issues would show in a public comment.
• A first answer to questions in Discussions. Name the categories in [discussions] answer_categories of config.toml, such as answer_categories = ["Q&A"], and run install of this release once: it writes the workflow discussion-assistant.yml, and every new discussion of those categories gets an answer of the AI from the code, the documentation, the issues and the other discussions, checked and cleaned as every analysis. The assistant posts one comment and never marks it as the answer, which the asker can do; it stays out of a discussion that a maintainer joined first, and a bug or a feature request gets a link to the form of an issue. The answers count toward max_per_day and max_per_author_per_day together with the new issues. Without a category, as before, nothing changes, also for a repository that only moves its pins: the new workflow is the only one that may write to discussions. The starter config.toml of a new set-up names Q&A, and the notice to reporters that install writes names the categories.

Every pull request of this release

Features

• a checked first answer for Q&A discussions (#144) (55da4ff)
• an evaluate command that measures label and duplicate accuracy on closed issues (#142) (01c8429)
• Codex, Gemini and Copilot as read-only engines next to Claude (#136) (a467a73)
• learn from the maintainers' corrections of earlier analyses (#132) (ab7a273)
• optional priority labels, area owners and native issue types (#137) (d6175d5)
• related issues from sibling repositories and a hint when an issue belongs elsewhere (#141) (7409122)
• ship the issue workflows as reusable workflows, so repositories update them with a pin bump (#128) (9465a79)

Compare with the previous release

Issue assistant v1.5.0

2026-10-14 · Release on GitHub

Added

• A set-up in four steps, without looking up a hash. install takes the commit and the tag of the release from its own clone, so git clone --depth 1 --branch vX.Y.Z and install are enough; it refuses the object of an annotated tag, which git ls-remote lists first, with the commit to use instead, and a commit or tag that isn't its checkout, whose templates it writes. install --setup also creates the environment issue-assistant on GitHub, for the default branch only, and has the GitHub CLI ask for the engine's secret. install now writes everything that check asks for: the section What happens with your issue in SUPPORT.md (in German for a file such as SUPPORT.de.md) where it doesn't name the AI yet, the runner of the AI and the ignored queue in an existing .github/actionlint.yaml, and, together with the starter labels, a bug report form with an Area field for a repository without issue forms, whose answers the labels area: setup and area: docs map. Each step looks first, so running install again changes nothing but the workflows. The README's set-up ends with a step that tries the assistant on an existing issue as a dry run, and turning off GitHub's auto-close of issues by merged pull requests is a step of its own.
• When a workflow or the firewall policy doesn't fit, check names the commands that write the templates of its release anew.
• Your own lifecycle in a new section [lifecycle] of config.toml: the days until the reminder (remind_after_days, 15) and the closing (close_after_days, 30) of an issue without an answer, until a sure duplicate closes (duplicate_grace_days, 3), the window after a release in which the reporter's comment reopens the issue (reopen_after_release_days, 30), and how often the AI follows up (max_follow_ups, 2). The comments name the days that you set, in English and German, and so does the section What happens with your issue that install writes. check names a period that can't work, such as a closing before the reminder, and a description of needs-info, stale or possible-duplicate in labels.toml that names other days.
• Exempt issues: the sweep never reminds or closes an issue with a label of exempt_labels, pinned and security unless you set others, and, if you like, one assigned to someone (exempt_assignees) or with enough 👍 (exempt_upvotes).
• Old threads can lock: with lock_closed_after_days, the sweep locks issues closed for longer as resolved, with one line that points to a new issue, 25 in a sweep. It never locks before the window after a release is over, an exempt issue, or one that someone unlocked. It is off unless you set it.
• A maintainer digest in the summary of the morning sweep: the open issues that wait on the maintainers (triage pending for more than 3 days, a reporter's answer, an objection to a duplicate notice), those that wait on their reporters with the day of the reminder or the closing, and the fixed ones that wait for a release, each a link, the longest waiting first and, among those of a day, the one with the most 👍.
• How well the assistant does, on the first day of each month and in every sweep started by hand: for the 30 days before, the analyses posted, the median time from a new issue to its analysis, how many labels of the AI the maintainers kept and how many they added, what became of the duplicate notices and of the questions to reporters, and the 👍 and 👎 on the analyses. The summary holds numbers and links only, never the text of an issue.
• Slash commands: maintainers steer the assistant from the issue, with a comment whose first line is the command. /assistant again asks for a new analysis, /assistant ask and a question gets the AI's answer from the code, checked as every answer before it is posted, /assistant duplicate #12 starts the closing of a duplicate after duplicate_grace_days (3 by default) and /assistant not-duplicate stops it, /assistant waiting marks the issue as waiting for its reporter, and /assistant mute and /assistant unmute keep the AI from starting anything on its own on the issue and let it again. The reporter may say not-duplicate, and ask once for a new analysis while the issue waits for triage, within the limits of the day. A 👀 on the comment shows that the command was carried out, a 😕 that it was refused, and the run says why. Run install again, which adds the task maintainer-question to Run workflow.
• Answers in the reporter's language. Besides English and German, the assistant now writes French, Spanish, Portuguese, Italian and Dutch, with its own words from a catalog for each language in locales/, including the days of the lifecycle and the dates of reminders, such as 2 novembre 2026. In any other language, the AI writes in it and the headings and the footer stay English, with dates such as 2026-11-02. The reminders, closings and release notes of the sweep keep the language of the analysis, which its hidden marker records, and before an analysis the reporter's own words decide. A new language is one more file in locales/; the French, Spanish, Portuguese, Italian and Dutch texts are machine drafts that native speakers are welcome to improve.
• Each task runs with its own model, turns and budget, from [engine] in config.toml. light_model runs the replies to one comment, which only say whether a maintainer's comment waits for the reporter or whether a problem persists after a release, on a cheaper model; max_turns (40) bounds a first analysis and a maintainer's question, a follow-up gets half of it and a reply a tenth, where every task had 40 turns before; max_budget_usd ($1.00) stops a run at that cost, so that no issue can make one run cost more; and effort sets how much a model thinks. check refuses values that the engine can't run with. The summary of every analysis job shows in one line, numbers only, what the run cost: its turns, time, dollars and tokens, also after a failure, with a warning that names the setting when the run stopped at its turns or its dollars. Install the workflows again to get it.

Changed

• The rules of the assistant are the engine's system prompt, apart from its task, instead of the start of one prompt in which the issue's own words competed with them. context writes them into .issue-assistant/rules.md, and its output prompt keeps both for the workflows of earlier releases until you install them again.
• Every analysis and follow-up says what it is and asks whether it helped. Its footer links How the assistant works, the part What happens with your issue of your SUPPORT.md, or of the first file of [transparency] files, and asks for a 👍 or 👎 on the comment; the summary of the morning sweep, or of one started by hand, counts them for the analyses and follow-ups of the last 30 days, as numbers only. On a duplicate notice, the footer says that a 👎 also keeps the issue open, as before.
• A long analysis keeps its questions in view: more than three links to related issues and files fold into one line below the questions, such as Where to look: 5 links, that opens them. A reminder links the comment with the questions that it reminds of.
• The comments speak of the maintainers, not of one maintainer, and the information needed says that an answer reopens the issue if it closes, not while it is still open.
• An analysis reads a window of the repository instead of every issue and pull request: every open issue, the 1,000 closed issues and the 1,000 discussions that changed last, and for a new issue up to 30 older issues that a search for its errors and the words of its title finds, so that old duplicates are still found. In a repository with tens of thousands of issues, the context stays small and takes a few calls to GitHub instead of hundreds. [context] max_issues and max_discussions in config.toml set the numbers. Each other issue comes with an excerpt of 400 characters, the pull request that fixed it, and its whole text for the AI to read when the excerpt looks promising.
• Deciding whether a maintainer's comment waits for the reporter, or whether the reporter's comment after a release says the problem persists, reads only the issue and that comment, no longer every issue and discussion of the repository.

Fixed

• A link to a line of a Markdown file, or of another file that GitHub shows rendered, such as reStructuredText, AsciiDoc, a notebook or an SVG picture, opens the file's source at that line. Before, it opened the rendered page, where a line has no anchor. A path with a backtick stays one piece of code in its link.
• Issues and discussions that the AI names as #123 stay links when they exist, up to ten of them, as the prompt asks it to name them. Before, every number but those of the duplicates and related issues showed as code.
• An issue that waits for its reporter closes on the day that its reminder names. The morning sweep starts a few minutes later on some days than on others, and when it started later on the day of the reminder than on the day it named, the issue closed a day late. The waiting now counts days of the calendar, in UTC, and the reminder records its day.
• An answer by an edit of the issue, which the questions offer, ends the waiting also when the event workflow missed it, so the issue no longer closes as unanswered, and a run again of the analysis no longer marks it needs-info. A second edit after a follow-up gets its own follow-up, as a second comment does.
• A new title is no answer. Fixing a typo in it removed needs-info, stopped the reminder and started a follow-up of the AI with nothing new to read.
• A comment of the reporter reopens an issue that closed for a missing answer also when an answer came in while the sweep closed it and took its labels. An issue that closed in another way since its last reopening stays closed.
• No follow-up is posted once a maintainer joined the conversation while the AI wrote it.
• A comment that someone else writes while the AI reads the reporter's comment after a release, such as "still broken for me too", no longer reopens an issue whose reporter just confirmed the fix: the AI judges the comment that started its run, not the newest one, and the issue reopens only for a comment of its reporter. In the same way, only the maintainer's comment that started the run can mark an issue as waiting for its reporter.

Every pull request of this release

Features

• /assistant commands for maintainers and reporters (#118) (bbb22ae)
• a maintainer digest and monthly quality numbers in the daily sweep (#120) (ebae9ab)
• answer reporters in their language, with the texts in locale files (#124) (70d4321)
• comments that explain themselves, take feedback and link every file correctly (#110) (0f068b3)
• lifecycle: configurable waiting periods, exemptions and locking of old threads (#116) (0ada1dc)
• per-task model, turns and budget, the rules as system prompt, and the cost of every run in the summary (#126) (f5bc6b2)
• setup: install without looking up hashes, set up the environment in one command, and try it right away (#108) (970c1b7)

Bug fixes

• lifecycle: keep the reminder, reopen and follow-up promises (#103) (3bdd0d9)

Performance

• build the engine's context from a capped GraphQL window and only what each task needs (#114) (3bd4cf9)

Compare with the previous release

Issue assistant v1.4.0

2026-10-14 · Release on GitHub

Added

• Try the assistant on an issue that exists nowhere: name a JSON file with the issue and its comments, as GitHub's REST API gives them, in the environment variable ISSUE_ASSISTANT_FIXTURE, and context and apply read that issue instead of one on GitHub and write nothing, as in a dry run. The project's own Canary analyzes such an issue every week with the engine, on the firewall runner, so that an update of the engine's action, a host that the firewall blocks or an expired secret shows before a release instead of as issues without an answer.

Fixed

• A fix that the morning sweep finds at the very end of the 14 days that it looks back closes its issue with the release that shipped it, as every other fix does. Before, the sweep labeled the issue but no longer counted the fix by the time of the label, so the issue waited for the next release, and its comment didn't name the fix. The sweep also no longer reads the issues that a recent merge names and that are closed already, most of them, so a busy repository spends far fewer of the 1,000 requests an hour that its token has, which its other workflows need too.

Security

• A table in the AI's text can no longer cut its code in two. GitHub splits every row of a table at each |, also inside code, so code such as `x|#1 https://example.com` in a row turned into text that referenced an issue and linked to another site, also in a table of one column, in a quote or in a list item. A line such as --|-- or :-:, which starts a table below its header, now shows as text, so the AI's text holds no table; the AI is asked not to write tables. A code block that closes with a shorter fence than it opens with, such as ~~~~~~ and ~~~, now counts as text too: GitHub's block ran on past it, into the next part of the comment, until the fence of the next code block closed it, and showed that code as text. A checked issue number right after an @, as in #0@GH-7, becomes code: once #0 was code, GitHub read @GH-7 as a mention of the user GH-7. A lone www., which GitHub links to the host www, becomes code. A link whose target holds a (, or entities that spell .., such as .., no longer stays a link: GitHub's target runs on past the ) that closes a (, and reads the entities, so either could lead out of the repository. New tests found all of these: they judge whole comments by a model of GitHub's rendering of their own, and fuzz them.

Every pull request of this release

Features

• try the assistant on an issue from a JSON file, and run the live AI path every week in a canary (#89) (859a509)

Bug fixes

• lifecycle: count a fix at the edge of the lookback, and skip closed issues (#106) (9dbec29)
• security: judge whole comments with an oracle of its own, and close the escapes it found (#87) (f730e7a)

Compare with the previous release

Issue assistant v1.3.1

2026-10-13 · Release on GitHub

Fixed

• A fixed issue that waited for an answer gets fixed-in-next-release again also when GitHub fails to list the releases while the morning sweep sees the merge. Since 1.3.0 the sweep asked first whether a release already ships the fix, so such a failure kept needs-info or stale on the issue, and the same sweep could remind its reporter or close it as unanswered. Now the labels come first, and the release closes the issue as before.

Every pull request of this release

Bug fixes

• lifecycle: write the labels of a fix before reading the releases (#93) (5bc204d)

Compare with the previous release

All releases of Issue assistant on GitHub

Repo Blueprint

Repo Blueprint v1.0.8

2026-10-24 · Release on GitHub

Bug fixes

• The checks pass with the newest Python: Python 3.14 warns of an HTTP error that is left open, and the tests fail on that warning, so the workflow Newest Python failed. The checklist (blueprint.py checklist), the dashboard, pins.py and downstream.py now close every HTTP error that they catch, with the answer of the server that it holds.
• The fix bot runs the fixes of your own checks: the step Checks of this project of scripts/check.sh, which runs scripts/check-project.sh, is indented within its if, and the fix bot and python3 .github/blueprint.py coach verify looked only for steps at the start of a line. So the fix bot never ran the autofix that .github/checks.project.toml gives that step, such as a script that writes the translations anew, and coach verify didn't ask for its explanation. Both now find a step that is indented by blanks or a tab.
• A pinned download of the blueprint whose sha256 disagrees with .github/pins.toml fixes itself: when the tests of the blueprint fail, the fix bot now runs python3 pins.py as well, which writes the sha256 of each pinned version, as after a version moved by hand or a download of Renovate that failed once. It commits what pins.py writes outside .github/workflows/; a workflow still needs a person.
• The link check passes again: since 2026-10-23, cwe.mitre.org gives the runners of GitHub no answer, so the link to the CWE Top 25 in SECURITY.md failed the workflow Links on main of every repository. The check now leaves out the links to cwe.mitre.org, and only those: a link to any other site that doesn't answer still fails it.
• The recording of copier copy renews itself again: since 1.0.0, Copier says five lines before its questions, and the picture bot of the website and the README timed out at the license, because the wait it used there reads only the first screen of the terminal. From the license on, each answer now waits for the line of the cursor, and a test keeps every other wait on that first screen.
• OSV-Scanner and Findings pass again for the test tools of Home Assistant: Home Assistant pins Pillow 12.3.0 and uv 0.12.23 for the tests of every integration, whose advisories no update can fix until it moves on, so OSV-Scanner failed, the code scanning alerts kept Findings red, and Renovate logged an empty commit for them in every run. The blueprint now accepts every advisory of those two versions in stacks/home-assistant/osv-scanner.toml, with the reason and until 2026-11-22, and a new Home Assistant integration gets the same osv-scanner.toml in its root. An integration that has an osv-scanner.toml already keeps it: copy the two entries of [[PackageOverrides]] from the blueprint's file into it.
• Renovate tries no fix of a version that osv-scanner.toml accepts: an entry of [[PackageOverrides]] with vulnerability.ignore accepts every advisory of one version, such as one that another package pins exactly; python3 .github/blueprint.py advisories --fix writes a rule of Renovate for each into .github/renovate-accepted.json5, which .github/renovate-blueprint.json5 extends, and the new step Accepted advisories of scripts/check.sh fails while the two disagree, or when OSV-Scanner would ignore an osv-scanner.toml for a key that it doesn't know. The update brings .github/renovate-accepted.json5 with the rules of the template; a repository with an osv-scanner.toml of its own, such as a Home Assistant integration, runs python3 .github/blueprint.py advisories --fix once and commits the file, which the fix bot does in the pull request of the update. Decision 0059 says why.
• Every merged fix reaches the next release, whatever its description holds: release-please skipped a pull request whose squash commit it couldn't parse, title included, such as an update of Renovate that quotes release notes or an advisory with a line like **[(Full, and the fix waited for another release, which didn't list it. Before release-please runs, the release bot now writes the title and the lines Release-As: and BREAKING CHANGE: of each merged pull request since the last release that can change it into the end of its description, as an override in an HTML comment that release-please reads instead of the commit. Decision 0060 says why.
• The release pull request changes only when its notes change: release-please rebuilt it in every run, also on the same commit, and every check of it started again, because the header of its description ended with a line end that release-please trims when it reads the description back. The header now ends with an HTML comment.
• The bot for failed releases leaves a release alone that runs again already: when you or another bot had started a failed release again before the bot did, its run of After the checks failed with "This workflow is already running", although the release went on and passed. The bot now looks at the run first and leaves it alone when it runs again or ran again, and takes that answer of GitHub as done too.
• The websites show their pictures again: since selectolax 1.0, the lightbox plugin took every picture out of the pages that it should have wrapped in a link, so no website showed a screenshot, a social preview or any other picture. The tools of the website now take selectolax 1.0.2, which fixes it, and the update brings them as .github/docs-requirements.txt. The build of a website now fails when a plugin takes a picture out of a page, and names the page.

Performance

• A page with a diagram loads no Mermaid: the websites drew each diagram live with Mermaid, about 1 MB on every page that has one, such as the page Automation of every website, which then loaded about 1.3 MB on a phone. Now they show the pictures that scripts/diagrams.sh draws, as GitHub does, only in the theme that the reader switches to and as the reader comes to them, and the page of the automation loads about 320 KB; the text of a diagram is the text of its picture, but it can no longer be selected or found by the search. Every repository gets the pictures of the page of the automation in .github/mkdocs-blueprint-diagrams/. blueprint.py site-check, which the check docs runs, now fails on a page that loads more than 1,200 KB at once and names what it loads the most: a page of your website with a large first picture, or with a mermaid block that bash scripts/diagrams.sh --extract has not made pictures of yet, needs that fixed after the update. Decision 0058 says why.

Every pull request of this release

Bug fixes

• close the HTTP errors that the scripts catch, so the checks pass with the newest Python (#399) (50b28a9)
• deps: update the issue assistant to v1.6.1 (#371) (1f4aef9)
• docs: make the docs pictures pass again and drop the link exceptions of pages that are live (#400) (aa80012)
• docs: the Links check passes again although cwe.mitre.org refuses the CI (#397) (4394846)
• leave a release alone that already runs again (#396) (22b3084)
• let the fix bot and the coach find indented steps, and let the fix bot run pins.py (#403) (f4f792d)
• security: accept the advisories of the test tools that Home Assistant pins, and skip Renovate's branches for accepted advisories (#398) (bdb9691)

Performance

• docs: the websites show the pictures of the diagrams instead of drawing Mermaid live (#393) (0506e8d)

Compare with the previous release

Repo Blueprint v1.0.7

2026-10-23 · Release on GitHub

Bug fixes

• Renovate keeps no issue open: the issue Dependency dashboard stayed open in every repository, and closing it brought it back with the next run of the bot, so no repository could have no open issue. Renovate's dependency dashboard is now off: routine updates merge on their own, what waits for you is a pull request, and what fails reaches the issue Renovate logs problems. With this release, the next run of Renovate closes the issue Dependency dashboard of each repository by itself. The checklist of blueprint.py now ticks Renovate off once it has opened a pull request, instead of once its dashboard is open (decision 0057).

Every pull request of this release

Bug fixes

• deps: turn off Renovate's dependency dashboard (#387) (46c078c)

Compare with the previous release

Repo Blueprint v1.0.6

2026-10-23 · Release on GitHub

Bug fixes

• deps: refresh pip-compile outputs (#377) (26941bd)

Repo Blueprint v1.0.5

2026-10-23 · Release on GitHub

Bug fixes

• deps: update dependency certifi to v2026.10.19 [security] (#379) (04ddbb4)
• deps: update dependency copier to v9.19.0 (#376) (a655658)
• deps: update dependency pillow to v13 [security] (fc8fb7b)
• deps: update dependency uv to v0.13.4 [security] (#380) (5c43be2)

Repo Blueprint v1.0.4

2026-10-19 · Release on GitHub

Bug fixes

• A Nextcloud app is signed with Nextcloud 35, on a PHP that it runs on: the release signs a Nextcloud app with the occ of the Nextcloud server that the blueprint pins, now Nextcloud 35, which stops on PHP 8.2 because it needs PHP 8.3 to 8.5. The signing now runs on PHP 8.4, so a release of a Nextcloud app no longer stays a draft for that; the PHP that the app itself runs on is still the one of appinfo/info.xml. A test now checks the PHP of the signing against the Nextcloud that the release downloads, so the next major version of Nextcloud that Renovate brings shows its PHP before a release does.
• The settings bot passes where GitHub keeps a switch of the security off: GitHub accepts the generic patterns of secret scanning (secret_scanning_non_provider_patterns) on a repository of a user and keeps them off, so settings apply found the same difference after every run and the Settings workflow failed on main of every repository, although it had applied the rulesets and every other setting. A switch of the security that depends on the plan of the repository and that GitHub accepts and keeps as it was, or a switch that GitHub doesn't offer at all, is now a notice under GitHub doesn't do this for the repository, which fails nothing, with the line of .github/repository.project.toml that stops asking for it; the bot asks again every time, so that a repository whose plan gains the switch gets it. Secret scanning, its push protection and every other setting that still differ after their write fail the run as before; the checklist shows such a switch with the neutral mark (decision 0055).
• The branch bot brings a pull request up to date across a change of a workflow: once main changed a workflow since a pull request left it, GitHub refused the update to the bot's token of the release app, which could not change workflows, so such a pull request, such as one of Renovate that updates the actions, stayed behind with a warning in every run and the Update branches workflow failed on main. The token may change workflows now, as Renovate's does; the bot still checks out only main and runs nothing of the pull request.

Every pull request of this release

Bug fixes

• deps: update dependency nextcloud/server to v35 (#330) (e94a67d)
• deps: update the actions (#325) (2893561)
• deps: update the actions (#369) (ab55a8a)
• let the branch bot update pull requests that change workflows (#361) (d26f5b6)
• make Settings pass where GitHub keeps a security setting off (#372) (40e96b3)

Compare with the previous release

All releases of Repo Blueprint on GitHub