Releases

4.11.12 9 October 2026

Added

• See and delete your Claude Code chats from the Claude tile

  A new Chats tab lists every chat Claude Code keeps on this PC, newest first, with its project, when it was last used and how much space it takes (sub-agents and file checkpoints included). Tap a chat to read or continue it; tick the ones you no longer need and they go to the Recycle Bin/Trash after a confirmation, so you can still restore them. A chat that is open or was written in the last few minutes is never moved.

• The Claude tile is redesigned to look and work like Claude Code

  Your sessions are now a list on the left and the one you pick is open beside it, so you always know which chat you are reading and writing to. Each session has its own colour and its own Clawd, Claude Code's mascot, which walks while it works, hops when it needs you, blinks when it is done and sleeps once it has ended. A session is named the way Claude Code names it (your /rename, or its own summary), with the project, branch and the first characters of its id under it, instead of three rows all reading "xenon". The open session reads like the terminal: a status line with the ✻ spinner and what Claude is doing, its model, permission mode, effort, context and cost, the plan as Claude Code's checklist, the last tool calls, the conversation, and a prompt box with "> ". A request from the session you are reading appears inside it; one from another session is a single line on top that takes you there. The 5-hour and weekly limits sit in the header, with the full details under Usage. On a narrow tile or a phone the list becomes a row of chips above the session. With nothing running, Clawd waits with the prompt to start a new session. A new session can start in plan mode, with edits accepted, or asking for everything, and with the effort you pick, the same options as the terminal; only what your Claude Code supports is offered, and never a mode that skips permissions. Type "/" to pick one of your commands or skills, with arrows and Enter. A session started from the tile now shows what it is doing and its last tool calls while it runs.

• Tiles can be resized from the top-left corner too

  In layout editing every tile now has a second resize handle at its top-left, just under its toolbar, next to the one at the bottom-right. To fill free space above or to the left of a tile, drag that handle instead of moving the tile first and then resizing it.

• File search answers while you type, and finds more of what you mean

  Results come from Xenon's index straight away, and what Windows Search adds (including files that only match inside their content) follows below a line, without moving the rows already on screen. While you keep typing a word, each letter only re-checks the previous matches: on a 2.5 million file C: drive a query went from 52 to 118 ms down to 19 to 54 ms, measured against the previous build. Folders are results too, in their own group, and words can match the folders above a file, so "download fattura" finds the invoice in Download. A file you opened from Xenon before is never pushed out of the list, and is found even with a small typo, like an app name ("spotfy"). Apps you launch from the search come first among equal matches. Searching inside documents now matches words as you type them ("fatt" finds "fattura"), as file names already did.

• The search is easier to read and to drive

  Results are grouped (Apps, Folders, Files, In the content). The empty search shows the files and folders you opened recently from Xenon; in the Search widget this is off unless you turn it on in Settings → Search and disk, because a paired phone sees that tile too. A Filters button adds type, date and size without typing them, as the same chips you can remove. In the search popup, an image result shows a preview beside the list. Ctrl+Enter shows the selected result in its folder and Ctrl+C copies its path.

• Search on macOS and Linux finds your apps, and on a Mac it searches inside files

  Off Windows the Applications group was always empty. It now lists the .app bundles on a Mac and the installed applications on Linux (the same entries your app menu shows). On a Mac the search also asks Spotlight, the way it asks Windows Search on a PC, so it finds files outside Xenon's index and words inside documents. Both are new on those platforms and still in beta, like the macOS and Linux versions themselves.

• The Disk tile tells you what changed, not only what is big

  The overview is now a bar of the whole drive split by kind (video, photos, music, documents, archives, apps, games, other files, the part Xenon cannot index, and free space), with a legend, and below it up to three lines worth reading: how much you can free right now, which folder grew the most in the last week ("The Download\Video folder grew by 11 GB in 7 days"), and, once there are a few weeks of history, when the drive fills up at the current rate or that it is stable. Anything in a Steam, Epic, Xbox, GOG, Riot, EA or Rockstar games folder counts as a game, whatever its extension. Xenon keeps one small reading per drive per day for 90 days to know this; it stays on your PC. Tapping the growth line opens that folder in the map. Explore has a new list of large files nobody has modified for over a year. The map has the path above it, so you can tap back to any level instead of one step at a time, and a file in the map, in the lists or among the duplicates has a button that shows it selected in its folder (on the PC; not from a paired phone, where it would open a window nobody sees). On a wide tile like the Xeneon Edge the bar and the lines sit beside the map.

• The Disk tile opens at once and never goes blank

  On a big drive the tile showed "Aggregating millions of files" for up to half a minute, every time you switched drive or tapped refresh: we measured 26.7 seconds on a 2.5 million file C: drive, almost all of it spent re-reading up to 2 GB of files to confirm duplicates. Duplicates are now confirmed in the background, starting from the first and last 64 KB of each file and remembering the result for files that have not changed, so the next analysis does not read them again. The tile answers with what is already confirmed and the list fills in by itself. That also removed the old 200 MB limit, which hid the duplicates most worth finding (ISOs, videos, game archives). A drive you return to is redrawn immediately and refreshed in place, an analysis is reused for as long as nothing on the drive changed, and after a restart the tile shows the last analysis with its age while the index is being rebuilt.

• A Deck key can switch to the first output that is connected

  Pick up to three outputs in order: First choice, If it is not connected, Then (optional). When you press the key, Xenon looks at what is plugged in at that moment and sends the sound to the first one on the list that is there: your headphones when they are on, the speakers when they are not. It works the same for a dock's DAC and the laptop speakers, or a TV and a monitor. If the first available output is already the one in use, nothing is switched, so the sound does not drop out for nothing. If none of them is connected, the key says so. Its face lights up while the first choice is the output in use. Widgets can do it too, with { type: 'audioDeviceFirst', device1, device2, device3 } under the existing audioDevice permission, so it asks for nothing new (WIDGET_SDK.md, section 5g). Asked on Discord for a key that closes a set of apps and then goes to "my Bluetooth headphones if they are connected, otherwise the speakers": until now that took two steps, passed through the speakers first and flashed red whenever the headphones were off.

• The "+" panel says where a widget is when it is already on your dashboard

  The panel only offers widgets that are not placed yet, so one you had added, Weather for instance, was simply missing from the list, and that reads as a widget that vanished. They are now listed too, under Already on your dashboard: the same items, quieter, each saying where it is (this page, another page by name, or a tab of this tile), and a tap takes you there, turning to the page and lighting the tile for a moment. The search finds them as well, so typing "weather" lands on it instead of on an empty list. If a widget is marked as placed but no tile is on any page, the tap puts it on the page you are on. Asked on Discord: "where is the Weather widget in my menu, it disappeared".

• A native package for Arch Linux and Omarchy (#133)

  On Arch Linux and the distributions built on it, npm run native:build:arch builds the Xenon app and packages it for pacman, so it installs, shows up in the app menu and uninstalls like any other package (sudo pacman -U). It is built on your own PC rather than downloaded, since the release builds run on Ubuntu. Because pacman owns the installed app, Xenon does not try to replace it; the dashboard still updates itself as usual. (Thanks to the community contribution behind this.)

• New ways to watch in the Twitch and YouTube tiles

  Under the video there are now three buttons. Cinema shows the video and the Twitch chat side by side, or for YouTube the video and your list, without the rest of the tile. Fill the tile gives the whole tile to the video, with the controls over the picture. Full screen now keeps the chat (or the list) next to the video, and a button switches it off when you want only the picture. The tile remembers the view you picked on each screen, so the Xeneon Edge and your phone can use different ones. Tap the same button again to go back to the normal tile; Esc or changing page leaves full screen.

• Choose which Twitch account the player in the Twitch tile uses, or watch anonymously

  The video in the tile is Twitch's own player, and it only knows you if you are signed in to twitch.tv in the browser that shows the dashboard. The account you connect in Settings → Streaming is what fills the lists, and the player cannot see it. In the Xenon app the player had never been signed in, so on the Xeneon Edge every stream played as a guest, even when your followed channels were on screen. A new account button under the video now says how the player is watching ("Signed in as …", or not signed in) and offers two choices: With my Twitch account or Anonymously. In the Xenon app on Windows, Sign in to Twitch opens Twitch's own sign-in page in a window on your main screen. You type your password into Twitch, not into Xenon. When you are done the window closes and the player starts again signed in, so a subscription or Twitch Turbo applies in the tile as it does on twitch.tv. Anonymously plays without your account but keeps your sign-in, so you can switch back at any time. In a browser, sign in on twitch.tv as usual; on an iPhone or iPad the player always watches anonymously. Ads that a streamer starts during the live go to every viewer who is not subscribed, signed in or not.

• The Twitch and YouTube tiles are rearranged so they have no empty space

  The video is now as large as the tile allows and the name and the controls sit right under it, instead of the video floating in a taller box with empty bands above and below. On a wide, short tile like the Xeneon Edge the video takes the full height with the list and the chat beside it; on a box-shaped tile with the Twitch chat on, the list goes under the video and the chat takes the full height on the right. When nothing is playing the tile shows only the list, which spreads over several columns on a wide tile, instead of a black box asking you to pick something. The channel or video that is playing is marked in the list, the tabs are plain words, and the chat has a header with the button that opens the full Twitch chat.

• A Codex tile for OpenAI Codex

  Add Codex from the "+" panel and it shows the usage windows of your plan, read from Codex itself (5 hours and a week on a paid plan, one 30-day window on Free), with the time to each reset and a marker for an even pace, plus your tokens per day for the last 30 days and the conversations Codex lists, the most recently active first. Tap one to read it: the open conversation keeps itself up to date, and while Codex is still working it also shows Codex's progress notes, which give way to the final answer when the turn ends. It covers Codex wherever you use it: the ChatGPT desktop app, the Codex extension for your editor and the codex command. Tap Codex → Connect and Xenon adds five small hooks to your Codex hooks.json (your own hooks stay as they are and a copy of the file is kept); after you trust them once in Codex with /hooks, the tile shows the sessions that are working and you can answer their requests on this screen: Allow, Deny, or Answer in Codex, which puts the question back in Codex at once. Each request says what it would do (the command, or the files a change touches, with deletes marked) and what makes it unusual, and a request that cannot be undone is allowed by holding the key. While a request waits here Codex does not show its own, so it goes back to Codex after 90 seconds (Settings → Codex changes this, or turns the requests off). Xenon never trusts the hooks for you: that step is Codex's own safety check and stays yours. Widgets can read the plan numbers through the new codex stream, which carries numbers only, never a folder, a project, a conversation or a command (WIDGET_SDK.md, section 3h).

• An Ask ChatGPT tile

  Add Ask ChatGPT from the "+" panel and type a question: the answer comes from your own ChatGPT plan, through OpenAI's Codex on this PC, with no API key. ChatGPT itself has no way for another app to read or continue your chats, so this is the route OpenAI allows: the answers do not appear in your ChatGPT history and are kept on this PC instead, up to 40 conversations. While an answer is being written the tile shows how long it has been thinking, with Stop; a follow-up carries the conversation so far. Chats lists your conversations, lets you delete them and pick the model, and the header shows how much of your plan's busiest usage window is used, since these answers count against it. It needs Codex installed and signed in (the ChatGPT app, the editor extension or the codex command), and says so when it is not.

• CPU and GPU temperatures can use their own unit

  In Settings → Weather, below Temperature unit, Hardware temperatures can be set to °C or °F on its own, so the forecast can be in °F while the CPU and GPU, the Guardian alerts and the game session recap stay in °C (or the other way round). It starts on Same as weather, so nothing changes unless you pick a unit. Installed widgets are told the hardware unit too (hwTempUnit).

• A Xenon mod for Claude Code

  Claude Code can now load mods, and Xenon has one. Pressing Connect Claude Code on the Claude tile now also asks Claude Code to install it, and starts with the next Claude Code session. A Claude Code connected earlier gets an Install the mod button on the tile, and the install can also be typed by hand: /plugin install xenon --marketplace marcimastro98/Xenon. Disconnect removes it. It needs a Claude Code that supports mods. The tile then shows which model each subagent runs on, and the context gauge and the 5-hour and weekly limits update as soon as they change instead of waiting for the next status line. In Claude Code, /xenon says whether the dashboard hears that session, without using any tokens. The mod finds Xenon through the connection the Claude tile already made, so there is nothing to pair. It sends numbers and model names only: never what you type, what Claude runs or the content of your files. When Xenon is closed the mod waits and tries again later, without slowing Claude Code down. Under the Claude Code prompt, a line appears only when something needs you: Xenon is closed or not linked, or an approval is waiting on the dashboard. While all is well there is no line; /xenon gives the detail. The line can be turned off in the mod's options. Also in the options, off by default: Approve from the Xenon dashboard. Permission requests then appear on the dashboard for a short wait you choose (30 seconds unless you change it); with no answer there, the terminal asks as usual. Only a tap on the card approves, and the card gets the command, file path or address, never the content. The existing connection keeps working with or without it.

• A Developer cleanup tile, for supporters

  On a PC used for development most of the full disk is not in your files: it is Docker images and build cache, local AI models in Ollama, VS Code and Cursor folders for projects you deleted long ago, and the virtual disks of WSL and Docker, which grow and never shrink by themselves. The Disk tile cannot see any of that. Add Developer cleanup from the "+" panel and it shows how much each one takes and how much you can free. Docker removes images no container uses and the build cache, with Docker's own commands (images in use and your volumes are not touched). Ollama lists your models to pick from; the one Xenon's AI uses is kept. Editor folders lists only the folders of projects that no longer exist on disk, and moves them to the Recycle Bin or Trash. On Windows, a WSL or Docker virtual disk of 10 GB or more gets a Compact button: Windows asks for administrator permission, Xenon closes Docker and WSL and shrinks the file. Each step says what happens before it runs. A source that is not installed or not running says so instead of showing zero. The tile is unlocked with your supporter code, typed right in the tile or already saved in Settings, and stays unlocked on that PC for good; without a code it says so and offers a way to become a supporter. The space numbers, with no names, are also open to any widget through the new devStorage stream (WIDGET_SDK.md); the cleanup itself is not, so a widget can never delete anything. The "+" panel marks it "For supporters", so you know before adding it. If Docker or Ollama is off, the tile checks again every 30 seconds while it is on screen, so starting them shows up without a refresh.

Fixed

• The Claude tile always shows the end of a reply

  With a session open in the tile, the terminal could finish its turn while the tile kept showing the conversation without the final answer. The tile read the conversation once when the turn ended, sometimes a moment before Claude Code had written the last message, and never looked again; a session that went from waiting on you to finished was not re-read at all, and an answer arriving late could overwrite a newer one. The tile now reads again a few times after every change until Claude Code has closed the turn, shows the final reply as soon as Claude Code reports it, never cuts the newest message short (older long ones have Show all), and offers a New reply button when you have scrolled up instead of jumping. A request left over from earlier in the turn no longer keeps the session marked as waiting after it has finished.

• In the Discord widget's Controls tab, the volume rows now sit below the people in your call

  The microphone and speaker volume used to sit between the buttons and the list of people, pushing the people down. The order is now the buttons, the people in the call, then the two volumes and the audio options.

• The Linux app no longer closes by itself a few seconds after opening

  4.11.11 moved Xenon's own screen checks onto the thread that draws the window, but the app could still quit with an "[xcb] Unknown sequence number" error, because something else in the app, such as the tray icon, could still talk to the display server from another thread at the same moment. Xenon now tells the display library at startup that it is used from several threads, so those moments wait their turn instead of ending the app.

• The Minimal bar's island fits the music again

  The floating island could never be wider than half the screen, so with the clock, date, weather and a song in it the title disappeared and the music controls ran into the page dots or past the island's edge. The island now takes the room its content needs, up to the width of the screen, and shortens the title only when the screen is really too narrow.

• Deck folder keys bring the folder to the front

  On Windows, a key that opens a folder opened it behind the other windows, or minimized, because Windows does not let File Explorer take the foreground on its own. Xenon now finds the folder's window and brings it forward, as app keys already did.

• Codex no longer reports an issue with Xenon's hooks

  Codex's hooks list showed "1 issue loading hooks", because Xenon marked its session-end hook to run in the background, which Codex does not allow for that event. The hook now runs the way Codex expects. Xenon updates it by itself the next time it starts; Codex may then ask you to trust the hooks again.

• The Codex tile shows the same plan limits as Codex

  Codex also reports extra limits, such as one named "gpt-reserve", that its own usage menu does not show, and the tile listed them as a third row nobody could place. The tile now shows the main 5-hour and weekly limits, and an extra one only when it is the limit that is stopping you.

• Widgets keep their size in the macOS app when the interface is scaled

  With the interface scale above 100%, the macOS app enlarged the inside of Store widgets such as Nocturne Now Playing without giving them more room, so their text looked blurry and their bottom controls were cut off behind scroll bars. The macOS app now scales the page the way Safari zoom does, so widgets stay sharp and fit their tile, as they already did in a browser and on Windows.

• The top bar keeps the same height from one song to the next

  The now-playing part of the bar took the width of each track title, so a long title squeezed the Lock, Ambient, Xenon and Search buttons into two rows and a short one let them back into one, making the whole bar change height with the music. The track text now has a fixed width in the full bar, so the layout only changes when playback starts or stops.

• Downloading Whisper works again

  Since September the whisper.cpp project no longer attaches its Windows files to its numbered versions, so Download Whisper (Settings → Xenon AI, and the "Hey Xenon" row) found nothing and stopped at once. Xenon now takes the newest build that has them. If a download does fail, the "Hey Xenon" row keeps showing why instead of switching straight back to the Download button. On Linux it now says to install whisper.cpp from your package manager, instead of trying to unpack the Windows build.

• The Claude tile follows a session that started before Claude Code was linked

  Such a session sends Xenon no updates of its own, so the tile kept showing it as it was when first seen: a session idle at that moment stayed idle, and its open conversation did not refresh while Claude was working. Xenon now reads its state from Claude Code's own session list, so it shows when it is working and the conversation updates by itself.

• Twitch search in the Twitch tile finds live streams by title and tag

  Searching "santa monica" found nothing, while twitch.tv showed a full page of streams. The Twitch service Xenon uses for search only looks at channel names, and those words were in the titles and tags of the streams, not in any name. The search now also looks through the live streams in your dashboard's language and the busiest ones in any language, and keeps those whose title, tags, name or game contain your words. Capitals, accents and spaces do not matter, so "santa monica" also finds the tag "SantaMonica". Channels named like your search come first, then the matching streams, busiest first, with their viewer count. The first search takes a few seconds; searches in the next minute are instant.

• Fewer Twitch ads in the Twitch tile

  Twitch's player plays an ad almost every time it starts, and there is no setting to turn that off. Xenon was starting it again more often than needed: adding, renaming, moving or removing a page, and rearranging the tile in its tab group, reloaded the stream you were watching, and every reload brought a new ad. The stream now keeps playing through all of those, so a new ad starts only when you pick another channel. Tiles with a web page or a widget inside keep their state the same way. On a paired iPhone or iPad the browser cannot do this yet, so there it works as before.

• File search finds names with accents

  Typing "citta" or "città" did not find Città.docx, and "universita" did not find "Università": Xenon removes accents from what you type, but compared it with the file names as they are written. Both the Xenon index and Windows Search missed them (Windows Search tells accented letters apart in a name search, which we measured on a real index). Names are now compared without accents on Windows, macOS and Linux, including names stored in the decomposed form macOS uses.

• Search on macOS and Linux returns the best matches, not the first ones found

  The index stopped at the first few hundred files that matched, in the order it had walked the disk, and only then sorted them. A file with exactly the name you typed could be left out because hundreds of files merely containing that word came first. It now keeps the best matches across the whole index, as Windows already did.

• On Linux the Disk tile counts caches, build folders and the Trash

  The Linux index skipped .cache, node_modules, .npm, .cargo, the Trash and similar folders entirely, so browser caches, package caches, build output and the Trash never appeared in the disk map or in Cleanup, however much space they took. They are now measured (they still never show up as search results). The tile also no longer says the index reached its safety limit when it had only found many large folders. Opening a folder in the map now shows that folder's real contents: before, Linux drew it from the drive-wide summary, which only lists folders of 10 MB or more and the largest files, so a folder of small files opened onto a single block of unattributed space.

• Switching drive in the Disk tile reuses the last analysis

  Tapping another drive always rebuilt its analysis from scratch, even when Xenon had just made one. It now reuses it when it can, and only ↻ asks for a fresh one. Tapping a second drive while the first one was still loading could also be ignored; it now always loads.

• "Keep games focused" works even with Game mode off

  The tray option that keeps your game focused while you touch Xenon only worked while Settings → Performance → Game mode was on, and that switch is about the background: it fades the aurora and the neon grid during games. Turning it off to keep your background therefore also let every tap on Xenon take the focus from the game, while the tray still showed the option ticked. The two are now separate: Game mode decides the background, and Keep games focused in the Xenon menu decides the focus. The display protection that stops Xenon from re-placing its window while a game changes resolution follows the game the same way. The crash log now notes when a game is detected and when it closes, so it shows whether the game was recognised. Reported on Discord by cosmolaris: "it will keep the mouse there, but not the focus".

• After a restart, Xenon opens on the screen you chose and not on the main one

  On Windows the screens are numbered in the order they come up, and after a restart the Xeneon Edge often comes up last, so the "Display 2" you picked could turn out to be your main screen. Xenon opened there as a small window and stayed there. It now also checks that the saved screen still has the shape of the one you picked: if the numbers moved it finds the right screen and remembers it under its new number, and if the Edge is not on yet it waits for it instead of using another screen. A screen whose resolution you changed is still recognised.

• Xenon no longer starts hidden at login

  If Windows had not made the screens readable yet when Xenon started, Xenon hid its window to wait for them and then never showed it again: it was running in the tray but nowhere on screen, which looks like it did not start. It now shows itself as soon as a screen can be read. Opening Xenon again while it is running also puts it back on its screen, like Show Xenon in the tray, instead of only bringing the window forward where it was.

• The Windows login entry has quotes around the path

  Xenon's entry in the Windows startup list was written without quotes, and under a user folder with a space in its name Windows could lose the part that tells Xenon it was started at login. The path is now quoted.

• The crash log says how Xenon started and where it put the window

  Every launch writes one line: started at login or by hand, the screen you chose, the screens it found and where the window went. Xenon also notes when it used another screen because the numbers moved, or waited for the Edge. If Xenon opens in the wrong place, choose Open crash log in the Xenon menu and those lines show why. Reported on Discord by JeeLR4M: "it opens as a window on my main screen and not in fullscreen on my Xeneon Edge".

• On a Mac, Xenon goes back to its screen after sleep

  When a Mac sleeps, a second display such as the Xeneon Edge goes away for a moment and macOS moves the dashboard onto the main screen. On wake Xenon tried five times in 15 seconds to move it back and then stopped for good, and on macOS the move from the main screen could fail because the window was sized before it had reached the other display. You were left with a small window on the main screen and had to bring it back by hand. Xenon now notices the wake, waits for the window to arrive on its screen before sizing it, and if the screen is slow to come back it keeps trying once a minute instead of giving up. What it did after each wake is written to the crash log (Xenon menu, Open crash log), so if it ever still happens, those lines say why. Reported on Discord by Piotr, together with the manual workaround that pointed to the cause.

• The calendar dots wear the colour of their calendar

  Each external calendar has a colour of its own (Settings → External calendars), but in the monthly view every dot was the accent green, both under the days and next to the events in Upcoming events. Only the list you get by tapping a day used the right ones. Now all three agree. A day with events from different calendars shows one dot per colour, side by side, up to three, and a day with a single calendar looks as before. A colour you change in Settings shows at once instead of when the events are next fetched, which could take up to five minutes. Reported on Discord by Piotr: *"I think the dots in the Calendar view should have the colors assigned to the calendars"*.

• The Volume tab keeps its volume card on a short System tile

  On a wide, short tile, the usual shape on the Xeneon Edge, the Volume tab stacked the volume card above the two device rows, and when height ran out the card was the part that gave way: first the list of apps, then the card itself, while Speaker and Microphone kept their full height. On a short tile the card now takes the width and the two device rows stand beside it, and the apps sit several to a row, so the slider and the per app volumes stay on screen. On an even shorter tile the title, slider and percentage share one line. A tall tile looks exactly as before.

• A Volume card hidden in Layout says so where it was

  Hiding the Volume card left the tab with only the device rows, and the only way back was a chip in the Layout panel. While you edit the layout, the tab now shows Volume card hidden with a Show button in its place. Outside Layout mode nothing changes, so a card you hid on purpose stays out of sight. Reported on Discord: "I only see the speaker and the microphone, not the volume bar".

• The Disk tile can install Xenon Helper itself

  When the helper that builds the disk index was missing, the tile said so and told you to run the installer again, which the setup .exe never shows anyone. On Windows it now has an Install Xenon Helper button, the same signed download the setup does, and if it cannot finish it says whether the download, the signature or the install was the problem. Reported on Discord: "how can I view the disk space?".

• Game mode says what it does, and the Settings search finds it

  While a game runs, the animated background (the aurora and the neon grid) fades out, and on a dark theme that reads as a black background. The description under Settings → Performance → Game mode only said it paused animated effects, so nobody connected it to the background. It now names the background, and searching for "black background" or "background goes black" lands on it.

• The volume mixer keeps listing your apps

  Since v4.10.0 Xenon reads the volume of every app only while you are using the Volume panel, and it stopped doing so two minutes after your last touch. The panel is fetched once, when it opens, so a game or a call that started later never showed up and the list sat empty. While a Volume or Microphone panel is on screen the dashboard now keeps that reading going, and it refreshes the moment you open the tab or swipe to the page. Nothing is read while no mixer is in view, so the saving that change was made for is kept. If reading the audio fails, the notice stays up and the panel recovers by itself once it works again. Reported on Discord, where the list had gone empty.

• On Linux the app goes full screen on the screen you picked (#134)

  On a Wayland desktop an app cannot move its own window, so Xenon opened full screen on whichever screen it first appeared on, often the one you were using rather than the Xeneon Edge or the screen chosen in Settings. Xenon now names the screen when it goes full screen, which Wayland desktops honour, and does the same on X11. (Thanks to the community contribution behind this.)

• The Linux app could close on Wayland desktops such as Hyprland (#133)

  On some Wayland desktops, the ones that use "explicit sync" (Hyprland, which Omarchy is built on, among them), the app could close with a "Missing acquire timeline" error. On a Wayland session Xenon now switches off the WebKit drawing mode that triggers it. X11 sessions are unchanged. (Thanks to the community contribution behind this.)

• A limited or purchased pack you saved keeps opening after it is updated

  A pack file saved before Xenon gave each version its own key does not say which key it was sealed with, and Xenon asked the unlock service for "the newest". That is the right key today, but it stops being the right one the day a newer version of the pack is published, so re-importing your original file, on a new PC for example, would have said the code was wrong. Xenon now asks for the first key, which is the one those files were sealed with. Updating through the Store was never affected.

• The Linux app could close by itself, often within seconds of opening

  Every few seconds Xenon checks which screens are connected, so it can keep its window on the one you picked. On Linux that check ran outside the thread that draws the window, and the two could talk to the display server at the same moment, which made the app quit with an "[xcb] Unknown request in queue" error. All screen checks now run on the drawing thread, on Windows and macOS too, where they were not causing a crash.

4.11.11 2 October 2026

Added

• A switch for automatic updates

  Xenon has always downloaded and installed new releases on its own, while you are not using the PC, on by default, but there was never a way to see that or turn it off in Settings. Settings → General → Aggiornamenti now has Aggiorna Xenon da solo. Off, Xenon still checks for new versions and still tells you when one is out; it just waits for you to press Update instead of installing it on its own.

• The text size setting is easy to find, and goes up to 250%

  It was always there, under Settings → General → Interface scale: a zoom slider that makes the whole dashboard, text included, larger. Nobody looking for a font size found it, because it is called a scale and a zoom, and it stopped at 160%, which is not enough for everyone. Now it goes from 60% to 250%, and typing "font size", "text size" or "bigger text" in the Settings search takes you straight to it, in all 11 languages. Its description now says it covers text and dashboard size. The row was also still in English in Spanish, French, German, Portuguese and Russian; it is translated now.

  Everything grows together, so the higher you go, the less fits on screen. The zoom applies to the Xenon app; in a browser, use the browser's own zoom (Ctrl and plus), and the slider in Settings adjusts the app on your second screen while you look at it.

• You can switch speakers or microphone without moving your calls

  Windows keeps two defaults for each direction: the default device, which games, music and videos use, and the default communication device, which Discord, Teams and other call apps use. Until now Xenon always changed both. A new switch in Settings → General → Audio, Also switch the communication device, decides. It stays on by default, so nothing changes unless you turn it off; with it off, the System tile, a Deck key or the assistant change only the default device and leave calls on the device you picked for them. Windows only, because macOS and Linux have a single default.

• Settings can install Xenon Helper for you

  The wave under the Media tile needs Xenon Helper to measure the sound, and when the helper was missing, too old or kept stopping, the line under the wave buttons told you to run INSTALL.bat again. If you installed Xenon with the setup, you never saw that file: it sits in a folder the setup does not show you. Worse, a helper that never arrived stayed missing for good, because Xenon only ever updated a helper that was already there. Now the same line has an Install Xenon Helper button. It downloads the helper built for your version and installs it only if it matches Xenon's signed release, the same check the automatic updates use. The wave starts straight away, with no restart. The button is only there when something is wrong, and it cannot be pressed from a paired phone or tablet.

• Search in Settings

  A search field at the top of the Settings sidebar finds a setting by name. Pick a result and Settings opens its section, scrolls to the row and highlights it. You no longer need to know which section a setting is in.

  The search works in all 11 languages Xenon speaks, and in English whatever language the app is set to, so "brightness" and "luminosità" find the same row. It forgives accents and a typo ("luminosita", "brighness"), finds a word in the middle of a Japanese or Chinese sentence, and in Korean finds a word from a half-typed syllable or from its first consonants (ㄴㅆ finds 날씨). It also knows the everyday words for each section, such as "dark" for Appearance, "fahrenheit" for Weather and "hue" or "wled" for Lighting.

  The arrow keys move through the results and Enter opens one. Ctrl+F or / jumps to the field while Settings is open, and Esc first clears the search, then closes Settings. With the field empty, it lists the last few settings you opened. On a touchscreen the field waits for your tap, so the on-screen keyboard does not open by itself.

• Widgets that chart which apps are busy open with the last five minutes already drawn

  A Store widget showing CPU, memory or GPU per app over time used to start empty and fill in while you watched, again every time you reloaded the dashboard or came back to its page. Xenon now keeps the last five minutes of those readings, the ones it was already taking, and hands them to the widget when it starts and when its page comes back into view. It stores nothing on disk and costs no extra work: the readings exist only while such a widget is installed and a dashboard is open. For widget makers, this is the new history message in the processes section of the SDK guide.

• Store widgets can have their own icon

  A widget from the Store showed the same puzzle piece on its tab in a tab group and beside its name in the + panel's search, so three Store widgets grouped together all looked alike. A widget can now bring its own icon, drawn the same way as Xenon's own widget icons so it follows your theme. Widgets without one keep the puzzle. For widget makers, this is the new icon field of manifest.json in the SDK guide.

• Search in the "Add widget" panel

  The panel you open with + now has a search field, so you can type "meteo", "cpu" or "musica" instead of scrolling through every category. It matches in all 11 languages, like the Settings search.

• Store widgets sit in the "Add widget" and "Add as tab" panels like Xenon's own

  A widget you installed from the Store used to hide behind a single "Custom widget" item: you added that tile, then picked the widget inside it, and "Add as tab" did not list Store widgets at all. Now each one is an item of its own in both panels, with its name, its author and its icon, filed under Productivity, Media, System or Streaming. A new row of filters above the list (All, Installed and each group) narrows it down, and the search looks inside the filter you picked, by name, author, description and group. Pick a Store widget and it goes on the page or into the tab straight away; its permission window opens only if you have not approved it yet, and cancelling it leaves the page as it was. The "Custom widget" item is gone from both panels; tiles you already have keep working. On a phone the panel is one column, the filters scroll sideways and every button is big enough for a finger. For widget makers, the new optional category field of manifest.json picks the group; without it, the group comes from the widget's Store entry.

• Add a widget to the page right after installing it

  Installing a widget from the Store, or from a code, now ends with a message that has an Add to this page button, instead of telling you to switch something on and find a tile. The same button is on every widget in the Store's Installed list. A pack with several widgets tells you they are under Installed in the + panel.

• A page that comes with a widget opens with the widget in it

  Importing a pack that includes a page and the widget it uses used to leave that widget's place on the page as an empty tile, with a "Choose a widget for this tile" list you had to answer yourself. Now the page opens with the widget already in its tile. Xenon still asks you to approve the widget's permissions, as it does for every widget, and it only fills a tile with a widget that came in the same pack. The Nitrato pack is the first to use it. For pack makers, a page item for a Store widget can now carry "pkg": "<widget id>".

• Supporter packs now offer their updates

  When a supporter pack you unlocked got a new version, Xenon showed nothing: no red badge on the Store buttons, no daily message, no Update button in Settings → Installed. Only opening the pack's own card in the Store would have told you. Now they appear like any other update. Update opens the usual import window and unlocks with the supporter code saved on this PC; if there is none, it asks for your code once and saves it, as a first install does. Nothing is swapped silently: you still see what is inside and approve its permissions again.

• Limited and purchased packs can be updated without typing your code again

  Until now, the owner of a limited edition, or of a pack bought with its own code, had no way to receive a new version: Xenon never kept that code, and a limited copy has no public file to download. Now, when a newer version is published, Update asks the supporter hub whether this PC has already unlocked the pack. If it has, the new version opens in the usual import window, where you still see what is inside and approve its permissions again. No code is sent and none is asked for. Limited-edition cards in the Store get the same Update button once you have an older copy.

  Each version of a pack now has its own key, so a key taken from an old version opens nothing published after it, and a pack whose code was revoked stops receiving updates. A supporter whose membership has ended can still update what they had already unlocked, but nothing new unlocks without a membership. If the hub does not know this PC, for example a copy you imported on another computer, Xenon says so and asks for your code once, as it did before. Store widgets that update themselves use the same route, so a widget you bought no longer waits for you to open it.

• Store widgets update themselves

  A widget you installed from the Store now gets its new versions without you doing anything. Xenon checks the catalog every few hours, waits at least a day after a version is published, and then installs it. It never raises a widget's permissions: if the new version asks for something you have not approved, it stays as it is, a message says an update is waiting for you, and you update it by hand as before. Supporter widgets update with the supporter code saved on this PC; without one they wait for you. A widget you suspended, one you built yourself and one that came inside a pack are left alone, and nothing happens in safe mode. The new version is prepared aside and swapped in whole, and the old one is put back if anything goes wrong; a version that failed once is not tried again by itself. The switch is Settings → Community widgets → Update widgets automatically, on by default, and under it Xenon says what it last updated and what is waiting for you. Themes, pages and Deck profiles are never updated this way.

• A new look for the new-drop window

  When a supporter pack or a limited edition lands in the Store, the window that tells you now leads with the pack's own picture, marks the offer with a gold crown for supporter packs and a violet gem for limited editions, and lights the card in the pack's own colour. A limited edition shows how many copies are left, and any drop with an end date shows how long it stays, both read from the catalog. On a wide screen like the Xeneon Edge the picture sits beside the offer, on a phone above it. When several drops land together they appear side by side in one window. It opens with a short burst of light and then holds still.

• This month's drops, each time Xenon starts

  The drop window used to announce each supporter pack or limited edition once, and then never again. Now it opens each time Xenon starts, once per session, and lists every supporter pack and limited edition from the last 30 days that you don't have yet: when a second one comes out, you see both. What you already installed is left out, and so is anything whose time or copies have run out. It is switched off in Settings → General → This month's drops, a new switch that starts on for everybody, including anyone who had switched off the previous window; the window itself has a link to it.

• A new Claude Code tile

  The tile is rebuilt around what needs you. A request Claude Code is waiting on sits at the top, whichever side of the tile you are on, and says what it would reach before it asks for a tap: publishing your work (git push, npm publish), the network, a file outside the project folder, or something that cannot be undone. A command that cannot be undone, such as rm -rf, is allowed by holding the button, not by a tap, and the buttons wait half a second after a card appears, so a tap meant for something else does not answer it. On a wide tile two requests sit side by side, and each card shows how long is left before the terminal asks instead.

  Live has a row for each session: its state, the step it is on and for how long, a line of its tool calls over the last ten minutes, its own plan, how full its context is, the sub-agents running and the lines it changed. Beside them, the 5-hour and 7-day quota are rows of segments with a mark where an even pace would be now, and one sentence under each: the share this pace ends the window at, or the time you would reach the limit.

  Usage covers one window and says which: the last 30 days, with today, since Monday, the total, the share read from cache and the value at API list prices, a column for each day, and the split by project and by model. When Claude Code has already deleted older sessions, it says from which date the figures start.

  The tile follows your theme in light and dark, lays itself out from its own size (a Xeneon Edge, a monitor, a phone), and speaks all 11 languages, including the units of time, which were Italian in every language ("4g23h"). Times follow Settings → Clock → Time format.

• A tidier Store

  Opening the Store now shows the Store. Updates for things you already have are no longer the first shelf you see: they wait on the Installed tab, whose red count says one is there, with Update all. New (what was published since your last visit) sits below the supporter packs instead of above them, and leaves out what you already installed. Supporter packs are shown as they are, without a padlock and a dark veil over the picture; the gold badge and the Unlock button say they are reserved. Cards drop the version number and the "May use more resources" note, which you still see in the detail view and in the import window before you install. The button on a free card is quieter, so the loudest thing on a card is an update waiting for you, and the shelves have more room between them.

Fixed

• Installing a widget over an older version no longer leaves the old files behind

  Importing a widget that was already installed wrote the new files over the old folder, so a file the new version no longer ships stayed there, and an install interrupted half way left a mix of the two. It now builds the new version beside the old one and swaps them, as the automatic update already did, so a failed install leaves the old version as it was.

• A Store pack with no version number now counts as installed

  The Store works out what you already have from your install records, and it skipped any record that carried no version, so a pack without a version number was not recognised as yours.

• The pictures in the Discord tile's notification list no longer flicker

  The Notifications tab redrew its whole list every time Discord sent a new voice state, which while someone is talking in a channel is several times a second, and each redraw built every picture again from scratch. Accounts with Discord's default picture flickered the most, because that picture does not always load, so its slot was added and removed at that same rate. The list is now redrawn only when something in it changes, and a picture that failed to load once is not asked for again. Reported on Discord.

• Tiles no longer cast a drop shadow

  Since v4.11.9 every tile had a soft shadow just outside its edge, and on a dark dashboard it read as a dark band behind the cards. It is now off everywhere, including on installs that already had it: the setting was renamed, so the old 100% saved in your settings, in your theme cards and in shared theme codes is no longer read. The Panel shadow slider (Settings → Appearance) still goes up to 200% for anyone who likes the look, and each tile can still set its own shadow in its style.

• A transparent tile no longer leaves a dark strip behind it

  Every tile casts a soft drop shadow just outside its edge. On a tile with nothing left inside it, which is a Deck with Base set to None or any tile whose opacity you took to zero, that shadow is all that remains on screen: about 18% darker along the bottom edge, fading over a dozen pixels, which looks like a card sitting behind the widgets. A tile with nothing in it now casts no shadow. Its border is unchanged, and a shadow you set on that very tile in its style is kept.

• A transparent Deck no longer loses its pencil and its profile switcher

  With Base set to None the Deck is just its keys on the dashboard, and its header, the profile name with the small arrow and the edit pencil, used to fold into an invisible strip that only came back when you hovered it or tapped just above the keys. Nobody found it, and without it there is no way into edit mode or to another profile. The header now stays on screen, drawn quietly: no button frames, the name at about half strength with a soft shadow so it reads on any wallpaper, and a row 20 pixels tall instead of 26. It comes to full strength when you touch it, focus it or use it. The keys sit a little lower than with the invisible strip, which is the price of the controls being there. The other Base finishes are unchanged.

• Tapping one side bar no longer opens the one on the other side

  With the minimal top bar, the two side bars tuck themselves away after 10 seconds without a touch, and then look exactly like a bar you closed yourself: just the small arrow at the edge. A touch on either arrow brought back both bars together, so the side you had left open slid out while the arrow you had actually tapped stayed where it was. "I press the right one and the left one opens, and the other way round." A touch now brings back only the side it landed on, including a touch on the bare edge of the screen. On a bar you had closed, that same tap opens it, so one tap does what it looks like it should. On a bar you had left open, the first tap only brings it back and the next one closes it, as before.

  The stored open or closed state of the other side is now read from the bars on screen instead of from a copy that could be a moment old, so opening one bar can no longer close the other one on the next launch.

• The Linux AppImage runs when another user starts it, or inside a sandbox

  One file in the package, the launcher Tauri adds (AppRun.wrapped), was stored so that only its owner could run it. Started normally that never showed, because the file belongs to whoever runs the image. When root mounts the image and someone else runs it, which is what Firejail does, it stopped with "Permission denied" and the app never opened. That is also why the AppImageHub catalog's automatic test of Xenon failed. The release build now puts that launcher in place with the right mode before packaging, and checks the finished image afterwards and warns if any file inside it could not be run by another user. It is a known bug in Tauri (tauri-apps/tauri#16155), so every app built with it is affected until it is fixed there.

• The dashboard no longer gets stuck on your main screen when a game turns HDR on

  Switching HDR changes the display mode, and Windows moves windows around when that happens. Xenon's native app got moved from the Xeneon Edge onto the main display, behind the game. It is supposed to put itself back within a few seconds, and it did when you switched HDR from Windows settings. Mid-game it waited for the game to lose focus, so it stayed hidden until you pressed Alt+Tab. That wait exists for a good reason: putting the dashboard back the usual way can pull the game out of full-screen. Now, during a game, Xenon slides the window back onto its screen with a plain move that never takes focus from the game and never touches full-screen, so it is back on the Edge a few seconds after the switch. The same applies to any screen you picked for it in full-screen.

• The × that removes a widget from a tab group sits in the middle of its box

  In layout editing, the red × on each tab was drawn as a text character, so it picked up the spacing of the tab's label and sat off-centre. It is now drawn as a shape and stays centred on every skin.

• A tile's editing buttons are in one row above it, and cover nothing

  In layout editing the buttons of a tile were spread over its corners, and the "+ Tab" pill sat on the bottom row of the widget, where it hid what was underneath and was easy to mistake for part of it. Now + Tab, Style, Save preset, Size, and Hide and Move to page (or Remove, on a copy) sit together in a bar at the top of the tile, which makes room for it while you edit. The buttons are bigger, spaced apart, and bigger again on a touchscreen.

• Store widget permissions no longer disappear once you have many widgets

  Xenon keeps which Store widgets you approved, and which tile shows which one, with the rest of your settings. Past roughly two dozen approved widgets that record grew over a size limit, and Xenon dropped it on the next save, so every Store widget asked for its permissions again and every tile showed its chooser. The limit now fits every widget you can approve.

• The assistant can build pages with every widget

  When the AI assistant builds or changes a dashboard page, it was told about the first 32 widgets only, so it could never place the newest ones, such as Search, Disk, File transfer or Phone. It now knows all of them. It also no longer places an empty Store widget tile that only asks which widget to show.

• A widget taken out of a tab group no longer stays on screen beside the others

  When a tab left a group, by its × or by cancelling the permission window of a Store widget just added as a tab, the tab disappeared but its content stayed inside the tile, drawn next to the tab you were looking at (often an empty Store widget chooser). It is now removed with its tab.

• A saved tile or page preset no longer brings back an old Store widget

  Inserting a preset with a Store widget tile could reuse a hidden tile and show the widget it held long ago, not what the preset saved. The tile now starts empty, as a newly added one does.

• The page buttons next to the page dots are easier to hit

  In layout editing, the buttons that move, rename, remove and add a page were small text characters packed against the dots, and the × was off-centre. They are now a separate group with drawn icons, spaced apart and larger on a touchscreen.

• Approving a Claude Code plan from the tile works, and the card offers what the terminal offers

  When Claude finished planning, the card showed Deny and Allow, and tapping Allow did nothing: Claude Code does not accept a bare "allow" for a plan, so the terminal kept waiting. The card now shows the plan with the same choices as the terminal: Yes, and use auto mode (or Yes, auto-accept edits where auto mode is not on), Yes, manually approve edits, and No, keep planning with a box to tell Claude what to change. The mode you pick is the mode the session continues in.

  Questions from Claude now reach the terminal as a normal answer. Before, the answer arrived as a refused tool call, so the terminal showed the question as rejected even though Claude used your choice. Question cards also gained the Other row the terminal has, so you can type an answer that is none of the options, and a question that asks for text or a number gets a box to type in. What you type stays put while the tile updates.

• A saved supporter code is recognised everywhere

  In Settings → Store, a PC that keeps your code now says Code saved with a Remove button, instead of an empty field and a Save button that read as "enter your code" to someone who already had. The Store recognises it too: supporter packs show one Unlock button that uses the saved code, and the supporter shelf stops offering the membership you already have. Whether the code still works is checked when you unlock, as before. The shelf's See all is gone as well, since the shelf already shows every pack.

• Widget names in Spanish, French, German, Portuguese and Russian

  Around twenty widgets (Weather, Calendar, Notes, Tasks, System, Cameras and more) showed their English name in the "+" panel and on their tiles. They are now translated; brand names such as Spotify or OBS stay as they are.

• The Deck editor no longer offers a per-app volume fader on a Mac

  macOS has no per-app mixer Xenon can reach, and the per-app volume keys were already hidden there, but the touch fader still listed App volume as a target and then never moved anything.

• The Mac installer's closing note about Full Disk Access is current

  It still said to grant the permission again after every update, which stopped being true in 4.11.3: the grant now survives updates.

• Claude Code questions reach the tile again, and taps on it are no longer lost

  These were two separate faults.

  The questions: the connection to Claude Code is a set of hooks in its settings.json. An install connected before newer versions added hooks kept the old set, so the questions Claude asks, and some session events, never reached Xenon. Xenon now checks the connection when it starts and when the tile opens, adds what is missing by itself, and the tile says so once and asks you to restart the Claude Code sessions that are open, because Claude Code reads its hooks when a session starts. If a part is still missing, the tile has a Repair button.

  The taps: the tile is redrawn every time a session reports, several times a second while one is working, and a button redrawn between your finger going down and coming up never receives the tap. That was "I tap Allow, or an answer, and nothing happens". The tile now finishes the tap before it redraws.

• The Claude Code usage figures are right

  • A session file over 64 MB was skipped, so a long session counted nothing and today could read 0 while you worked.
  • Work done by sub-agents was not counted.
  • A resumed session repeats earlier messages in a new file, and they were counted twice.
  • The value at API prices used one rate per model family and a flat cache multiplier. It now uses Anthropic's list price for each model, including the separate rate for one-hour cache writes.
  • A session that moved into a subfolder was split into two projects. Each project is now named by the folder the session started in, with its parent folder when two names are the same.
  • The usage figures mixed all-time totals with 30-day ones. They now all cover the same 30 days.
  • One quota window reporting on its own blanked the other, and a window past its reset kept showing its old figure until the next report.
  • Ages such as "5 min ago" stood still between reports. They now move every second.
• Performance Mode no longer stays on forever when you start it with no game open

  Pressing Optimize on the System tile while you were just using the desktop started a session with nothing to end it: it only knew how to stop when the game it was started for closed, and there was no game. It stayed on for days, with animations paused, the Windows power plan on High and the heavy tiles paused, and nothing on the dashboard showed it. Now a session like that ends by itself after 20 minutes in which no game runs and none of the activities you ticked in Settings → Performance is in front, with the usual "settings restored" notice. A session started for a game still ends when you close the game.

  While a session is on, the Optimize button on the System tile turns into a filled Restore button, so you can see it is on and turn it off with one tap.

• The Browser widget no longer ignores what you type while Performance Mode is on

  With the mode active and Pause heavy tiles while gaming switched on (the default), the tile stopped loading pages without saying why: you typed an address, pressed Enter, and got a spinner or a black panel. Now the tile says it is paused and has a Show anyway button. Typing an address and pressing Enter also brings it back, because that is you asking for the page. It goes back to pausing the next time Performance Mode turns on.

  The Second screen and Cameras tiles pause for the same reason, and they did it just as quietly: the second screen held its last frame, and the cameras kept their last snapshot, which on a camera looks like nothing is happening. Both now say they are paused and have the same Show anyway button. The camera snapshots also dim while paused, and opening a camera full size resumes the tile, so the big view is never a frozen image.

• New drops and announcements now reach a dashboard that stays open

  The window announcing a new supporter pack or limited edition checked for news only once, twenty seconds after the dashboard opened. A dashboard left on for days, like the Xenon app on a Xeneon Edge, never heard of a drop published after that, and if the one check found you in a game or on the Ambient screen for five minutes, it gave up until the next restart. Now it looks every few hours while the dashboard is open and again when you come back to it. It still shows at most one window a day and never the same drop twice. Announcements from the hub follow the same rule.

4.11.10 26 September 2026

Added

• Xenon AI can use your Claude or ChatGPT subscription instead of an API key

  Two new providers in Settings → Xenon AI: Claude Code and Codex. Xenon AI then answers through the official Claude Code or Codex program installed on your PC, signed in with your own Claude or ChatGPT plan, so there is nothing to pay per message.

  Xenon never sees, stores or forwards your credentials: you sign in inside the program, through Anthropic's or OpenAI's own sign-in, and Xenon only asks the program for an answer. This is also the only way Anthropic allows a Claude subscription to be used outside its own apps, which is why Xenon does not offer a "Sign in with Claude" button.

  The settings panel tells you whether the program is installed and signed in, with your plan, and if not, exactly what to run; when Xenon cannot tell, it says why. You pick the model from a menu filled by the program itself, the same list its own model picker shows for your account (today Sonnet 5, Opus 5.5, Fable 5.1 and Haiku 4.5 for Claude Code, and Codex's own catalog for Codex), so new models appear there without waiting for a Xenon update. Under the menu you see the exact model in use. Asking for the list sends no message, so it costs nothing. Codex does not need to be installed as a terminal command: Xenon also finds the copy that comes with the Codex desktop app or the ChatGPT extension for VS Code and Cursor.

  The assistant can do everything it does with the other providers: change the theme, set up Deck keys, add tasks and timers, control lights and media, search the web, and the rest. Xenon's own tools reach the program through a small bridge that lives for a single answer, with a key of its own that stops working when the answer is done. The program's own tools, such as its terminal and file access, stay switched off: through Xenon it can only use Xenon's tools.

  What to expect. It is slower than an API key: a few seconds for a plain answer, around ten when it uses a tool, because the program starts for each answer. It uses the same subscription limits you code with. Voice works and stays on the free local speech. The features you start yourself (AI search, the disk advisor, Performance Mode planning) use your subscription too, while Bit's automatic one-liners never do.

• One Deck key that switches between two audio outputs

  Asked for on Discord by someone who had built it by hand on a Mac: a shell script that flipped the sound between the monitor's speakers and a USB DAC, and then told Xenon which one was on so the key could change its icon.

  Switch between two outputs, in the Audio actions, does all of it. Pick the two devices from the list of what is connected, and each press moves the sound to the other one. If the sound is on a third device, the first press goes to the first one.

  The key's Look while active now shows up when the second device is playing, and it follows the output that is really active, not the last press. Change the output from the Windows sound settings or the Mac menu bar and the key catches up by itself within a few seconds, which the script could never do. After a press on the key itself it changes straight away. A plain Output device key does the same thing for its own device: it lights up while that device is the one playing. Keys you already have pick this up the next time you save them.

  If one of the two devices is unplugged, the key tells you that device is not connected instead of switching to the one that is left. On a Mac, switching outputs still needs SwitchAudioSource (brew install switchaudio-osx), the same as the Output device key.

  Widgets can do it too. { type: 'audioDeviceToggle', deviceA, deviceB } is part of the existing audioDevice permission, so a widget that can already choose your speakers does not need to ask again, and it can ship the toggle as a Deck macro. Xenon decides which way to go at the moment of the press, so a widget never switches the wrong way because its last audio update was a few seconds old. Documented in [WIDGET_SDK.md](docs/WIDGET_SDK.md) → *Moving the sound between two outputs*.

• Ambient can be the screen Xenon starts on

  Asked for on Discord by someone whose Ambient scene is their whole dashboard: *"On startup/restart I need to press the button in the top left for ambient mode. Having the option to skip that and boot straight into what the button press would take me to would be swell."*

  Settings → Ambient → Open at startup does exactly that. Every time Xenon starts, the PC boots or the app reloads after an update, your scene opens on its own and stays up until you close it.

  The inactivity start that already existed could not do this job, and the reason is worth knowing if you use both. It is a screensaver: it waits for the whole PC to go quiet and closes the moment you use the PC anywhere, which is the opposite of a scene you look at while working on another screen. Open at startup behaves like pressing the button yourself. Moving the mouse, typing on the main screen or starting a game leaves it where it is. The scene's own buttons still do what they did before, so tapping the weather still opens the weather view.

  It waits for anything you have to answer or read first, the morning greeting or a dialog, rather than landing on top of it. And a start that is still asking the first-run questions, the choice of screen or the short tour, is left to them: the tour points at parts of the dashboard a scene would cover. The next start opens as usual. If your scene is a community one you have not approved yet, it opens the classic scene instead of asking for permission the moment the PC boots.

• The Weather tile can show current conditions on one line

  Asked for on GitHub (#130): *"Is there a way to not waste that entire screen space on that blue background with a moon? I just want the next hours/days, with a summary of the current temp/feels like."*

  Settings → Weather → Current conditions → One line swaps the big animated card for a single row: the condition icon and the temperature, the condition with feels-like right under it, and wind and precipitation a step quieter on the right. Everything below it, details, hours and days, gets the space the card used to take. On a tile shared with other widgets that is the difference that matters: in the height where the big card leaves room for today's forecast only, the row leaves the hourly strip and all three days in view with space to spare, so the tile can be made shorter and the rows handed to something else.

  The obvious catch was that the big card is also the button that opens the full weather view, so shrinking it could have cost you the way in. It doesn't: the row is that button now, and a small arrow at its end says so, because a strip does not look tappable the way the big card did. Tapping opens the full weather view over the dashboard, as before; the tile itself never grows, so nothing around it moves. Wind and precipitation follow the same Details to show toggles as the big card, and on a narrow tile they step aside, precipitation first. Feels-like never does.

  It stays a strip across the top at any size. The wide layout that puts the card beside the sections was the other way to save height, and the request was clear that it needed the width for other things, so a compact tile never switches to it. The big card stays the default, and the modal is unchanged.

• A widget can turn the dashboard's page

  The same move the new page shortcuts make, handed to the SDK: a control-room tile with a button per page, or one that brings the media page up when something starts playing.

  { type: 'dashboardPage', page: 'work' }, or next / prev / back. Only the screen the widget is on turns, pages belong to a device's own layout, so a phone and a desk PC do not have the same ones and neither should follow the other's widget, and a page this screen does not have is refused rather than redirected somewhere arbitrary.

  It is its own permission, not a corner of an existing one: a widget that can turn the page can take the screen away from what its owner was reading, which is a different kind of act from drawing inside its own tile. There is no confirm dialog, because what travels is one of the user's own page ids and the result is visible the instant it happens.

  Documented in [WIDGET_SDK.md](docs/WIDGET_SDK.md) → *Turning the dashboard's page*.

• Turn the dashboard's page without touching it

  Asked for on Discord by someone running Xenon on a second screen: *"switch or toggle dashboard pages while another app has focus."*

  A second screen is something you look at while working in something else, which is exactly when reaching over to swipe it is the wrong move. Settings → General → Page shortcuts binds key combinations that fire while any other application has focus: one per page, next / previous, or back to the last page, which is what "flip between my two pages" really means, and it keeps meaning it once there are three.

  Each row says for itself whether the desktop gave it out. A combination another app already owns (PowerToys Run famously owns Alt+Space) reads *already used by another app* on that row, and the other shortcuts still work, one clash no longer costs you the rest. The press reaches every screen watching, and each one turns to that page if it has it, so the phone in your pocket ignores a page only the desk has instead of jumping somewhere arbitrary.

  Nothing new is watching your keyboard: the same helper that has always held the Spotlight shortcut now holds a list instead of one, on one message loop, and on Linux each shortcut is an entry in your desktop's own keyboard settings (GNOME) that you can see and delete like any other.

• And every disk, one by one

  The other half of the same request: *"let a widget list all detected disks and allow the user to select which ones to display individually."* Nothing per-disk was collected on any platform, so this is three implementations behind one shape.

  The diskIo stream gives each physical disk its read and write throughput, its read and write IOPS, a stable id, the model, the serial, the size, and the volumes that live on it, so a row can read *"Samsung 990, C:, D:"* rather than a device name. Partitions are folded into their parent, because a partition's counters are already inside it and listing both would double every number on screen.

  Disk temperature is null on Windows and macOS, and a real number on Linux where the kernel publishes one. That is a decision, not an omission: reading it elsewhere means a SMART query, and the way to get it would run that on every sensor read, waking a spun-down mechanical drive every few seconds for everyone, including the people with no disk widget. Until it can be charged only to whoever asks for it, null is the honest answer.

  Pulled like network, so on Windows its three CIM queries run only while a granted widget is on screen asking for them.

• A widget can now see every network adapter separately

  Asked for on Discord by someone building a workstation monitor on the SDK: *"list all system network adapters instead of only the currently active/global traffic"*, a 10GbE NAS link, the internet link and a VMware VMnet, each on its own graph.

  The data was always there and always thrown away: all three collectors read every adapter and returned the sum. The new network stream carries them one by one, a stable id, the name you gave the adapter in Windows, the hardware description, whether it is up, the link speed, and read/write throughput per second, plus the raw counters if you would rather do your own maths. Virtual adapters are included, which is the point of the request; downloadBps/uploadBps stay the sum of the physical ones, because a VPN or a VMnet carries the same packets a second time.

  It is its own grant rather than a field on system: this is traffic, not a sensor, and the permission dialog says which it is. It is also pulled, not pushed, a widget asks at the cadence its graph wants, and while none is on screen asking, nothing runs. An adapter that has only been seen once reports null rather than a spike the size of its lifetime counter, and one that is unplugged simply leaves the list.

  Documented in [WIDGET_SDK.md](docs/WIDGET_SDK.md) → *Per-adapter network*.

• The File transfer tile now explains itself

  Asked for on Discord: *"how did you pass a file from phone to PC? It isn't written anywhere, put a button or an info in the widget that explains it on click."*

  It was written down, in FEATURES.md, which is not where anybody is standing when the question comes up. The tile said *"drag files here, or send them from your phone"* and stopped there, and the step that matters most is the one it could never have shown you by existing: the phone has to be paired first, or it cannot send anything at all.

  A ? beside the title opens the steps. From the phone: pair it once (Settings → Phone → Add device, then the phone's camera at the QR code), which opens Xenon in the phone's browser, add it to the home screen and it becomes an icon you can reopen any time, then Send to PC in the bottom bar. From the PC: drag the files in, then download them on the phone. Under that, where arriving files land and how to move that folder, and then the limits (same network or Tailscale, one file at a time, and on an iPhone the two things iOS itself does not allow), taken from the phone sheet that has worded them since 4.11.0 rather than written a second time.

  It is a button and not four permanent lines, because a tile you have used once should be a list of files and not a manual. It opens over the list rather than above it, so a short tile does not lose its files to it, and the phone's sheet gets the same ? in its own bar.

• Discord servers fold away in the Channels tab

  Asked on Discord: *"It would be nice to be able to collapse the Discord servers underneath the Discord Channels feature so your not forever scrolling."*

  Every server heading is now a button. Tap it and its voice channels fold away behind a caret, with a count of how many are in there while it is shut, so a server you never join costs one line instead of fifteen. Collapse all / Expand all sits above the list and does the lot in one tap; it is one button rather than two, because while anything is open it closes everything and once everything is closed it opens it again.

  What you closed is remembered, the same request asked for it to stick "on future uses", and remembered by the server's id rather than its name, so it survives a rename. Favourites never folds: pinning a channel to the top is the shortcut past the scrolling, and hiding it would work against the point.

  A rename is not the only thing the id fixed. Channels used to be grouped by server *name*, so two servers that happen to share one (a "Friends" and another "Friends") were silently merged into a single list. They are now two, as they always were in Discord.

  SDK widgets on the discordChannels stream get the guildId too, so they can group and remember servers the same way, see [WIDGET_SDK.md](docs/WIDGET_SDK.md).

Fixed

• Bigger Store items install

  The Store accepted an item's install code only up to 2 MB, and a supporter pack with painted background images, a widget and an Ambient scene is around 3.5 MB once locked: it had to be split into separate items. The limit is now 4 MB, so a pack like that is one item and one install. On an older version those items say "Requires Xenon v4.11.10" instead of offering an install that would fail.

• Settings now tells you whether the Media tile's sound wave can work on your PC

  Asked on Discord: *"how do I install xenon helper for media visualization?"* The wave draws the sound the playing app is really making, and that measurement only exists through Xenon Helper on Windows. Without it the wave simply stayed empty and nothing said why. Next to the wave switch you now see whether Xenon Helper is running, missing, too old or stopped, and what to do about it: running INSTALL.bat again installs or updates it. On a Mac or Linux it says the wave is Windows only, instead of suggesting an install that cannot help.

  Worth knowing if your player seems ignored: the wave, like the Media tile, follows what Windows reports as playing. Some players, Winamp among them, only report it with a small plugin.

• A streaming login that fails now says why

  Reported on Discord: connecting Discord ended in *"Could not start login. Try again"* and nothing else. That sentence was where every failure without a message of its own ended up: an error inside Xenon, a server that did not answer, or credentials that were missing. Each one now shows its reason and, where there is one, Xenon's own words about it. The same goes for Twitch, YouTube and Spotify.

• The voice orb no longer needs a Gemini key when Xenon AI runs on Claude or ChatGPT

  Push-to-talk in the chat already transcribed your voice with the matching provider, but the voice orb sent it to Gemini whatever you had chosen, so with Claude or ChatGPT and no Gemini key it could not hear you. It now uses the free local transcription with Claude, and OpenAI's own transcription with ChatGPT, exactly like the chat does.

• A custom widget follows its own tile's accent and background

  Reported by a widget author: the Accent set in a tile's customization showed on the tile, while the widget inside it kept drawing the dashboard's global accent.

  Xenon hands each widget the colours of the tile it sits in, read from the tile itself. Two of those colours, accent and background, are set up so that a theme change fades smoothly, and the browser hands those two back in a different format from the others. The step that tidies the colours before sending them only understood the usual one, so it threw both away and sent the global colours instead. It now understands both formats. The tile's accent and background reach the widget, and every other colour was already arriving correctly.

• The slideshow keeps changing pictures while you play

  Reported on GitHub (#130): *"the photos changing still freeze when in game on the latest version."*

  Stop GIFs while gaming, on by default, was meant to spare the game an animated GIF redrawing itself every frame. It did more than its name said: it also stopped the rotation, so a folder of photos sat on the same picture for the whole session. On a Xeneon Edge the screen is right next to the game and you look at it the whole time, so that was the wrong trade.

  Now a game only keeps animated images still. The photos carry on changing at the time you set, each new one loading behind the current picture and taking its place when it is ready, so the tile never flashes blank. The back and forward arrows work during a game too; before, they did nothing until the game closed. The slideshow still stops completely when nobody can see it, with the dashboard hidden or Settings open over it. The hint under the option now says what it does.

• A Deck key's Hold works from a touchscreen on macOS

  Reported on Discord by someone with three AppleScripts on one key, Tap, Double and Hold, where Hold never fired.

  macOS has no touch support for USB touchscreens, so apps like Touchscreen Gestures turn your touches into mouse clicks, and a long press into a right click. The Deck only counted a hold when the left button stayed down for half a second, so on that setup Hold could not happen, and the right click ran the Tap action instead. A right click on a key now runs its Hold action straight away. This also gives you a quick way to reach Hold with a mouse. Keys without a Hold action behave as before, and a long press on a touchscreen with real touch input works exactly as it did.

• An update no longer resets the style you gave each card

  Reported on GitHub (#130): *"there is a (minor) bug on update where all of the opacity settings I set per card reset."*

  At startup the dashboard reads your saved layout a moment before the part of the code that checks a card's style has loaded. Until now, a style it could not check yet was treated as no style at all. Usually that did no harm, because the copy on the PC arrived straight after and put everything back. But if anything saved the layout in that short window, which the first start after an update makes more likely, the stripped version counted as the newer one and replaced the copy on the PC. After that there was nothing left to restore it from.

  It hit every per card setting, not just opacity: colours, font, corner radius, glass, border, shadow, shape, background and decorations. It also explains an odd detail. A widget you had duplicated kept its style while the original next to it lost it, because copies already had this protection and originals and tab groups did not. They all have it now. The style is carried through unchecked for that one moment and checked properly on every read after it, and by the server on every save.

  Styles that were already lost cannot come back from this fix, so the cards will need setting again once. After that they stay.

• Xenon now checks WHICH Hue bridge it is talking to before handing over its key

  Raised alongside a batch of local customisations asking for *"secure discovery, pairing and API communication"* with Philips Hue.

  A Hue bridge's certificate is signed by Philips' own private CA, so no public trust store can verify it and certificate checking has to stay off. That is a decision about the signature, and it was quietly standing in for a decision about the peer: with nothing else checked, Xenon sent its bridge key to whatever answered the stored address. It takes something on your own network, so it is not much of an attack, but the ordinary way to get there is a DHCP lease moving the bridge's address onto another device, and then the key goes to a stranger's box because the router reshuffled.

  The certificate is no longer trusted for being signed; it is checked for being the bridge's. A Hue bridge's certificate carries its bridge id as its name, and the bridge id is exactly what discovery and pairing already read, so pairing, the one moment the bridge is standing in front of you with its button pressed, now records it alongside the key it hands out. An install that paired before this still gets the check: the id is read from the bridge once and remembered.

  A peer that cannot be identified is refused rather than waved through, and the refusal happens while the socket is being inspected, before the request that carries the key is allowed to use it, not after.

• The Playback tile no longer pushes the artist name out through its own bottom edge

  Reported with a screenshot of the line sliced in half along the frame: *"the title is limited to 2 lines and if the text is longer, ellipsis is inserted. The artist name is moved outside the frame."*

  The tile rearranges itself as it is resized, and three separate steps hand the title a second line. Each of them was written about the tile's width, with its height taken on trust, and below roughly 200px that trust is misplaced, because the second line does not come out of empty space. It comes out of whatever is under it. Which thing got pushed out depended only on which rule had granted the line: on a wide tile the artist, on a narrow one the transport buttons, and the tile clips either without a word.

  A short tile now gets one line and an ellipsis whatever its width, which is what the report itself proposed, and shorter still the provider chip steps aside before the title has to. Underneath that, two things now hold regardless of the numbers: neither the title nor the artist can be squeezed below its own line (a box shorter than a line is not a shorter title, it is a row of half-letters), and the text block can never be taller than the row it sits in.

  Measured across every tile size from 220×110 to 1000×480 with three title lengths: 328 of 4560 sizes put something outside the frame, the worst by 71px. Now none of them do.

• "Spotify is busy" now says for how long

  Reported from the same thread: *"I hit the rate limit, waited 24 hours, and the limit persists"*, against a dashboard that kept promising to retry shortly.

  Spotify answers a refusal with how long to wait, and Xenon already held itself to it. It just never passed the figure on, so every message read the same whether the wait was four seconds or the rest of the afternoon, and at the long end "retrying shortly" reads as a broken integration rather than as a wait with an end. Anything from two minutes up now names the wait, everywhere the tile mentions it; below that the old wording is still the honest one.

  Worth knowing if you see it often: the quota is your own Spotify app's, not Xenon's, the Client ID in Settings is yours, and an app still in Spotify's development mode has a much smaller allowance than one with extended quota.

• A Spotify list that failed to load is no longer shown as an empty one

  Reported as *"preserve loaded content during temporary failures and provide clearer status messages."*

  The widget already rode out Spotify's brief refusals everywhere else, the player keeps its last state, the queue is kept on purpose, the transport controls fall back to Windows' own media keys. The Devices and Playlists lists did the opposite: any answer that was not a list became an empty list, which the panel then reports as "No devices found", a confident statement that the account has none. The Devices tab reloads on every poll while it is open, so one refused request was enough for your speakers to disappear until a later one happened to succeed.

  A list that loaded now stays put, and the panel only says something is wrong when it has nothing to show at all, and then it says which: Spotify is busy, the account is not linked, or it could not be reached. A genuinely empty account still reads as empty, which is the half of this that was worth keeping.

• A native helper crashing could take the whole server with it

  Reported as *"handling for a broken connection to the Living Index helper so Xenon can continue running and use its existing fallback behavior."* It was every helper, not that one.

  Xenon talks to its native helpers over a long-lived pipe, the file index, file search, the phone host, screen capture, the PowerShell collector worker, the media host, the disk shell-delete child and the dictation recorder. Each wraps its write in a try/catch and retires the helper when it exits, which looks like enough and is not: a write that races the helper's death, exactly what happens when one crashes mid-request, fails with EPIPE after the call returns, reported as an event on the pipe rather than as a thrown error. Nothing was listening, and an unheard error of that kind ends the process. A helper dying, which every one of these features is written to survive, instead closed the dashboard.

  All eight now listen. The long-lived hosts take themselves out of service, so the next request gets a fresh one instead of timing out against a dead one; the one-shot children are already finished with by the time it matters. Reproduced first, the crash is a race, so the test provokes it rather than describing it, and a second test walks the source for any child pipe Xenon writes to without listening.

• °F now means °F everywhere, not only in the weather

  Reported as part of a batch of local customisations: *"I extended the selected Celsius/Fahrenheit preference to CPU/GPU header temperatures and ambient notifications, including thermal warnings and session summaries."*

  The setting is labelled Temperature unit, and it reached the forecast and nothing else. Anyone running Xenon in °F read the weather in °F and the CPU and GPU headers, the Guardian overheating toasts, the sustained-thermal warning, the unusually-hot notice and the game-session recap in °C, all on the same screen, none of them saying which was which.

  Every one of those now follows the preference, in all eleven languages, down to the Settings line that quotes the thresholds the thermal alert fires at. Nothing stored changed: Celsius remains the only unit inside Xenon, the sensors, the saved history, Guardian's thresholds, and the conversion happens at the moment of drawing, so switching the unit needs no re-fetch and never reinterprets a number that was already written down.

• A Deck key set to Image Fit → Icon lost its title

  Reported from a Xeneon Edge: *"Fill or Fit: the key label is visible. Icon: the key label is not visible. I tried S, M and L for the label and it makes no difference."*

  The cap lays its icon and its title out as a column. The title is one line and can be squeezed to nothing; the icon carried an explicit pixel size and could not be squeezed at all, so when the two did not both fit, the title was the only thing that gave, and it gave all of it. Fill and Fit never showed it because their title is a scrim painted over the picture rather than a row under it, and Icon was the worst case of the three: its picture is sized to half the cap (against 40% for a built-in vector), and as an inline image it also dragged the descent of the icon's own font along beneath it, a band of dead space as tall as a sixth of the icon, taken straight out of the title. At icon size L on the Edge, where 4.11.9 lets the icon keep growing with the cap, that came to more than the cap had.

  The title is now the fixed part of the cap and the icon is what yields: it keeps its size wherever there is room, which is almost everywhere, so nothing moves on a normal deck, and gives room back only when the alternative is a caption cut in half. The dead band under the picture is gone. Built-in vectors got the same treatment, which also fixes a title clipped on a small cap by a key bound to a live value.

• The list of received files could be wiped at startup, and the files with it

  Reported as *"in the images widget, if I delete one photo they all get deleted and there is no way back."*

  The delete was not the cause. At startup Xenon checks its list of received files against the folder holding them, and a folder it could not read was treated as an empty folder, so every entry was dropped as "the file is gone", and the emptied list was written over the good one. One unreadable moment (antivirus holding the folder, a OneDrive-backed profile not yet materialised, a half-mounted user profile) was enough. The dashboard went on showing the old list until the next request made the server answer with nothing, which is exactly why it looked like the delete did it, and the startup after that deleted the files themselves, as files nothing referenced any more.

  A folder that cannot be listed now changes nothing: every entry is kept, nothing is written, and the next clean start reconciles as before. A file that cannot be inspected keeps the size it was stored with instead of being dropped. Reproduced and pinned in the tests, both ways, a blind start must lose nothing, and a real one must still notice a genuinely missing file.

• Removing a file from the list can be undone

  The other half of the same report. The bin is labelled *"remove from the list"*, but with the copy into your own folder turned off that list holds the only copy, so it was a permanent delete wearing a mild label. The row now leaves the list immediately and offers Undo for twelve seconds, with the file kept aside until the offer expires. A delete that fails says so, instead of looking like it worked.

• The Deck's "Output device" key can finally be filled in

  Asked on Discord after trying the Sound control panel name, the sound-processor name (*"NVIDIA HD Audio, Realtek HD Audio"*), both together, and the PowerShell device names, *"all do not work and give an error"*.

  They could not have worked. The key's Device field was a text box, but the server only accepts an output device's id from the live enumeration, an opaque string like Speakers\Device\High Definition Audio Device\Render, which is not a name anybody would call their speakers. So every name anyone could reasonably type was refused. The check itself is deliberate and stays: that same id namespace also names *microphones*, and accepting an unmatched string would turn "move my sound to the other speakers" into "change my default mic".

  The field is now a picker, like every other Deck field that chooses from a live list. It lists the output devices that are actually connected, by name, marks the one in use, and stores the id for you. A key already pointing at a device that is unplugged right now keeps it instead of being quietly blanked when you open the editor. The key is also hidden on machines with no audio control to enumerate with, rather than offered and always failing.

• The Settings sidebar gives its space back to the categories

  The block under the list held five stacked rows: Support, Community Discord, Report a bug, Check for updates and the version. On a 1600×900 desktop that was 178px of a pane 202px wide; on a Xeneon Edge it was most of the pane, and the categories scrolled through what was left. Now it is two rows of two: Support and Discord side by side, Report bug and Updates under them, then the version. Every action is still there and still labelled; the labels are short and the full wording is in the tooltip. When an update is available the Updates button gives way to the "Update available" pill as before, and Report bug takes the whole row.

  The block is pinned, on every screen: those four are in view the moment Settings opens, without scrolling to the end of the list. 4.11.8 had let it scroll away on short screens because it was too tall to pin; small enough now, it stays. And the "Sostieni Xenon" entry at the very end of the category list is gone, a duplicate of the Support button under it, which now opens that page.

• Settings rows are rows, not boxes inside boxes

  Every on/off option in Settings, 131 of them, was drawn as a bordered, darker box inside its section card, with the label and its explanation side by side on one line, each squeezed into half the width and the text touching the edge of the box. Now an option is a plain row: checkbox, bold label, the explanation under it at full width, and a highlight only when you hover. Nothing moved and nothing was renamed; the pages just read as lists. The light and comic themes, which painted those boxes their own way, follow. Two more things the same pass measured on every page and fixed: a card that ended with a row, a note or a button had its last line 1px from its own border, and now has room under it; and on the two-column pages (Generale, Aspetto) cards were laid out in rows, so a short card beside a tall one left a hole under it. Cards now pack like a mosaic, each into the first free space.

• The bar at the bottom of Settings reads as two controls, not a paragraph

  Restart and Reset each had their explanation inline, beside the button, so the row was one long line of small print with two buttons somewhere in it, and on a narrower window the note on the left was cut to "Le preferenze restano s…". Each explanation now sits under its own button, two short lines, with the note and the saved-state message on the left and nothing truncated.

• The live file index holds its place in memory at a third of the cost, and the number Settings shows for it is the real one

  Measured on the author's PC with three drives indexed (1.98 million files): the index process held 814 MB, while Settings said "~603 MB". The figure came from the .NET garbage collector's view of its own heap, not from the process, so it never counted what the process actually kept.

  Three things changed inside the index. File names are stored once, as compact UTF-8, instead of as a full .NET string each (plus a second lowercase copy for the 40% of names that carry a capital letter). Folders are a tree instead of 280,000 full-path strings. And finding a path again goes through a table of integers instead of a dictionary entry per file. On the same 1.88 million files of C:, the index now sits at 156 MB at rest, and search and the Disk map answer exactly what they did before (verified answer by answer against the previous build; the Disk map's folder totals now also list folders that only contain subfolders, which used to be missed).

  Two more leaks are closed. After answering a burst of requests the process used to keep the garbage from those answers for as long as it sat idle (measured: 110 MB above the index for a whole hour). It now hands that memory back to Windows within seconds of going quiet. And the buffer that collects file changes was 64 KB, a ceiling that only applies to network shares: every time a build tool overflowed it, the whole drive was re-read (minutes at a full core). It is 2 MB now.

• The index's file limit follows your RAM, and Settings warns you before you hit it

  The limit was 2,000,000 files on every PC. It is now derived from the machine (2 million on 8 GB, 6 million on 32 GB), and Settings → Search says when the index passes 85% of it, with the percentage and the exact limit, so you can trim the list of folders before search silently stops seeing new files. The "limit reached" message still names the drive that was left out.

  *The index lives in the Xenon Helper; a fresh install gets the new one, and an existing install refreshes it with the next update.*

4.11.9 20 September 2026

Added

• You can re-order the list of stocks by dragging

  Asked on Discord: *"is there a way to re-order the list of stocks? besides deleting and re-adding"*. There was not, the Borsa tile drew the watchlist in the order it was stored, and adding a symbol always put it at the end, so putting one at the top meant removing everything above it and adding it all back.

  Each row now has a handle on its left. Drag it and the rows move under your finger; let go and the order is saved. The scrolling ticker reads the same list, so it follows too, and so does any SDK widget on the stocks stream.

  It is built for the screen it lives on: the handle is always faintly visible rather than waiting for a hover the Xeneon Edge will never get, a row swaps after half a row of travel rather than a whole one, and a quote arriving over the live feed mid-drag no longer rebuilds the list out from under you. A single symbol shows no handle, one row cannot be out of order.

• A Deck key's second face can now carry a real icon, not just an emoji

  Asked on Discord as *"is it possible to assign two icons to a single button in the Deck widget and toggle between them"*, answered with "a key can already carry two faces", and then, on trying it: *"is this feature active? I cannot find it."*

  It was active, and it was narrower than the answer implied. The face shown while a key's state is ON took an emoji, a label and a colour: a text box capped at eight characters. So "two faces" meant two emoji, and someone looking for the icon picker found a field asking for 🔴.

  The active face now takes exactly what the normal face takes, an icon from the built-in library, a picture you upload, or an emoji, through the same picker and the same checks. A microphone that becomes a crossed-out microphone while muted, a record dot that becomes a stop square while recording: the icon swaps the instant your script posts the state, on the dashboard and in the Virtual Deck alike.

  An uploaded picture sits as a compact icon rather than taking over the whole cap, so the flip is a glyph changing and not the key changing shape. Faces set before this keep working untouched, including inside shared profile codes.

  It also says where it is now, which was half the problem: key editor → Effects → Look while active. It had been described as living under Appearance, which is not where it is.

• You can pick a track out of the Spotify widget's Up Next

  Asked for on GitHub: *"I'd love to be able to actually pick from the spotify playlist showing in Up Next. Unfortunately I can see it all, but can't press any of them. I can only use back and forward."*

  Tap any row and it plays. Not just that song either, when the queue belongs to a playlist or an album, Xenon starts it inside that list, so playback carries on through the rest exactly as it would in Spotify itself, rather than stopping dead at the end of the one track you picked.

  A track that was dropped into the queue by hand belongs to no playlist, and Spotify's API gives no way to tell those rows apart from the outside. So Xenon tries the list first and plays the track on its own if that is refused: a tap always plays what you tapped. And a row Spotify won't name a track for (the odd local file or unnamed podcast episode) stays plain rather than looking pressable and doing nothing.

  On a touchscreen the play button is always there instead of waiting for a hover it will never get.

• The Media tile can show the sound wave of what is playing

  Asked for by a supporter on Buy Me a Coffee: *"wish there was a media bar and visualization"*. The bar was already there, the now-playing strip in the top bar, with cover and transport, under Settings → Dynamic Island. The visualisation was not.

  Settings → Aspetto → Riquadro Media now offers Nessuna / Minimal / Onda, coloured by the album cover, the same colours the LED strip already takes from it.

  It is an addition, and it behaves like one. The tile is unchanged: the strip is added underneath the content, it can never move or cover a control, and Nessuna is the default and draws nothing at all. Minimal is a thin line along the bottom edge that breathes with the music, for anyone who wants the dashboard to stay quiet; Onda is the fuller strip. Neither competes with the cover or the title, both are drawn under the artwork rather than on top of it.

  It is not decoration. Xenon can measure the peak level of each app about twelve times a second, and every bar in the strip is one of those measurements: the last few seconds of them, scrolling past, newest on the right. So a quiet passage looks quiet and a drop looks like a drop. It reads the *player's* level specifically, so a Discord call or a game never makes your music dance.

  What it deliberately is not is a spectrum analyser. Xenon measures one number per app, not frequency bands, and drawing sixty bars from one number would be a picture of nothing. The same reason the placeholder equaliser in this tile has never animated.

  It needs Windows with Xenon Helper, peak levels cannot be read without it and there is no fallback, so everywhere else the tile draws no wave at all rather than faking one, and the setting says so under the choice. Picking Minimal or Onda is what starts the measurement, and Nessuna stops it again; nothing runs while the tile is off screen, the music is paused, or the dashboard is in the background.

• A second Discord tile, showing a different tab

  The widget has four tabs, Controls, Channels, Soundboard, Notifications, and only one could be on screen at a time, because only one Discord tile could exist. Asked for by someone who wanted his DM notifications above and the voice-chat controls below, on the same screen.

  It can now be added twice from the "+" palette, and each tile remembers its own open tab. Both read the same connection to your Discord app, so the second one costs no extra polling, and when either tile is showing Notifications, the unread badge stays where it belongs: at zero.

• The Windows downloads are signed

  Until now Xenon-Setup-x64.exe arrived as a file nobody had vouched for, and Windows treated it that way: browsers cancelling the download, "unknown publisher" on the setup, Defender quarantining it outright. There is a code-signing certificate behind the release now, and the installer carries a real publisher name.

  Two honest limits, because this is not a switch that turns the warnings off. SmartScreen can still appear for a while: since 2024 Microsoft grants no certificate instant trust, and reputation is earned through downloads over time. What changes is that it now accumulates against one stable identity instead of resetting with every release. And a signature is not a verdict: the app executable inside the installer and the companion helper are signed too, but Defender judges behaviour as well as identity, so a flag on a brand-new file remains possible until the reputation has had time to build.

  If you have hit any of this, the README section still explains how to check a download by hand and restore a quarantined file.

Fixed

• Xenon now starts even when Node.js lives somewhere unusual

  Reported by someone whose partner's Xeneon Edge worked on the first try while his own never came up: the setup found every component, said it was done, and the app sat on *"Xenon isn't finished installing"* forever. A full uninstall and reinstall changed nothing. His Node.js was on a second drive, at F:\Nodejs.

  The engine is started on Windows by a small hidden launcher, and that launcher asked the system to find node by name. The installer resolves Node properly, it had already printed the exact path, run npm with it and ticked every box, but the launcher threw that away and started from scratch, with whatever environment Windows happened to hand the startup task. A Node.js anywhere but the two or three usual folders is not in it.

  Worse, the whole failure was silent. Nothing was started, so nothing wrote a log, so the setup could only report that *something* had not answered and reinstalling could only find everything in place again.

  The installer now writes down the exact node.exe it verified, and the launcher starts that one. If it has gone missing, the launcher looks in the usual folders and then through PATH itself, by hand, one folder at a time, which is also how it stops depending on cmd being findable, the same failure issue #127 caused on a PC whose PATH had been rewritten by a "debloat" script. And if there is genuinely no Node.js on the machine, it says so in server.log, the file the setup and the app splash already tell you to send, instead of leaving it empty.

• The Slideshow's frozen picture no longer shows a broken-image icon and a pale border while you game

  Reported as: *"it works fine on desktop, but pauses with a white border and a little picture broken icon top left corner"* when a game is running.

  While a game has the machine, the slideshow paints its current picture onto a still and drops the live one, that is how an animated GIF stops costing anything. Dropping the live one means hiding it first, and the hide was doing nothing: five of the widget's pieces set their own display, which quietly overrules the browser's own way of hiding an element. So what stayed on screen was a picture with no picture in it, sitting behind the still: its empty frame around the edges and a broken-image icon in the corner. It only showed with Whole picture fit, where the still doesn't reach the tile's edges, which is why it took a while to surface.

  Fixing it fixed three more of the same, all shipped and none reported: a slideshow holding one image kept its back/forward arrows and its position dots, both pointing nowhere, and the pause badge sat on every tile whether it was paused or not. Hiding now works on everything in the tile, written once so the next piece added can't quietly opt out of it.

• The interface scale is now in Settings wherever you open them, and it works from there

  Reported by someone who arranges their dashboard from a browser on their main monitor while the app runs on an Edge: *"the scale UI option appears only if you go in settings from edge screen, it was not shown in the settings from my browser on main screen… I spent much time trying to figure it out, and even coded a little upscale in my widgets in the beginning."*

  Two faults, and the first is what made the second look reasonable. The scale is stored with the rest of your settings and already reached every screen, but the only thing that ever handed it to the app was opening Settings on the app itself. A scale set anywhere else sat there, saved and ignored, until you opened Settings on the Edge or restarted it. So the control was hidden everywhere else, because from everywhere else it would not have worked.

  It works now: the app picks the scale up the moment it arrives, so moving the slider in a browser rescales the app on the Edge while you watch it. And since it works, it is shown, on every screen, with a line under it saying that it resizes the app, not the browser window you happen to be in.

• Long dropdowns stay inside the frame in the Xeneon Edge preview

  Reported from the Deck's action picker: *"part of the list displayed when you configure a key is outside the window. Top of the list is not visible."*

  The preview renders the dashboard as a fixed 2560×720 stage, scaled to fit your browser window, and hides anything that falls outside it, that is what makes it a faithful frame. But the floating menus were positioning themselves against the browser window instead, which in that mode is a promise of space that isn't there. A 50-row menu was placed partly above the stage's top edge and the frame simply cut it off. Measured at 110 pixels of list lost, with no scrollbar to hint that anything was missing, since as far as the menu knew it had fitted comfortably.

  Both floating menus now measure the stage: the shared dropdown panel and the Deck's profile switcher, which is attached to the very element the stage is made of. They cap their height to the room actually available and scroll instead of overflowing, exactly as they already did on a real Edge.

  A second fault came out with it. Inside the preview the page is *scaled*, so a menu's on-screen size and its own layout size are different units, and the positioning code was mixing the two, which left the panel landing short of its own field by the scale factor. It now measures that ratio from the menu itself rather than reading it off the page, so nothing changes at all when there is no scaling.

• A Deck key can point at %APPDATA%\Spotify\Spotify.exe and it will work

  Reported alongside another issue: *"I got a button to the exe but it tells me the path doesn't exist when I push it (but again, it does)."*

  It does exist. Windows writes paths that way in its own dialogs, every install guide quotes them that way, and both Win+R and the Explorer address bar expand %APPDATA% on the spot, so the path reads as real everywhere a person can check it. Xenon was the only thing in the chain not expanding it, so the key reported "not found" about a file sitting right there, and the field looked perfectly correct.

  Whole %NAME% pairs are now expanded before the path is looked up, from Xenon's own environment and with no shell involved anywhere. It is deliberately cautious: a path that already exists is never reinterpreted, an unknown or empty variable abandons the attempt rather than quietly dropping the segment (%NOPE%\x.exe must never become \x.exe), a stray percent sign in a folder name is left alone, and the expanded path still has to clear every check the typed one did. Applies to Open app, Open file/folder and Run script alike, the same three actions the macOS and Linux path repairs already cover.

• The Slideshow tile now says why it is empty, instead of asking you to add images you cannot add

  Reported from a folder on a NAS reached over a UNC path: *"NO error displays, but the photos slideshow shows 'No images yet' with an 'Add Images' button"*, while the same pictures in a folder on C:\ worked.

  The tile was showing the library's empty state to someone whose source is a folder. "Add images" is the right prompt for a library you fill by hand and a meaningless one for a folder, so the message both withheld the problem and pointed at the one thing that could not be the fix. Everything needed to say the real thing was already there, the server answers with a reason (folder missing, not a folder, not allowed, unreadable) and Settings has shown those exact sentences in all eleven languages since the folder source shipped. Only the tile threw them away.

  It doesn't any more: a folder that cannot be read says so on the tile, with Open settings rather than Add images.

  It also names the one cause that reads as nonsense otherwise. Told a network folder "does not exist", the reporter mapped the share to a drive letter, pointed Xenon at that, and was told the same, *"it doesn't exist, but it truly does."* It does; it does not exist to that process. Windows scopes mapped drives and saved share credentials to a logon token, and Xenon's startup task runs with the elevated one, which is a different session from the Explorer window that made the mapping, so the letter is genuinely absent and the share has no credentials, while a folder on C:\ is unaffected. Where the path is a network one (a UNC path, or a drive whose root Xenon cannot reach), the message now says that instead of leaving you to doubt your own file manager.

  And a folder that reads perfectly but yields nothing is now told apart from an empty one. "0 images found" was true in both cases and useless in both: it could not distinguish *put some pictures in it* from *these are not files Xenon can read*. The tile and the settings line now say how many entries were passed over, "No readable images in this folder (517 entries skipped)", which names the supported formats and makes the difference visible instead of leaving an empty tile and no thread to pull.

• Copying a Deck profile onto a second Deck works even when a profile of that name is already there

  Reported after duplicating a dashboard page to reuse a Deck setup: *"The list has 2 items, but they are early obsolete versions… the one with the green bullet is the current one, but it is not visible on the second page."*

  From another Deck in the profile menu was dropping any profile whose name this Deck already had. So the moment an old *Nocturne Control* landed on the new Deck, the current *Nocturne Control* was hidden, hidden precisely because the stale one was sitting next to it. With nothing else to offer, the whole section disappeared, and the feature read as simply not working. It also kept only the first profile of a given name across Decks, so which of three namesakes you were handed came down to storage order.

  Neither rule survives. Every non-empty profile on every Deck still on the dashboard is listed, each row carrying how many keys it holds, the same thing that already tells two namesakes apart in the recovery list below it. A Deck no longer on the dashboard still stays out; that gate was never the problem.

  And copies no longer pile up under one name: the second copy of *Nocturne Control* is saved as *Nocturne Control 2*, the way a second download is numbered. Where a Deck already carries namesakes from before this, the profile switcher now shows the key count on those rows, so the five identical lines in that report can be told apart without opening each one.

• A Deck profile now looks the same on every screen it is opened on

  Reported with two screenshots side by side, the same profile on a desktop browser and on a Xeneon Edge: *"icon scaling is inconsistent between the web app and the macOS app"*.

  The key caps grow to fill the space the Deck is given, but the icon and the title on them did not: both stopped growing at a fixed pixel size, tuned for the largest key-size preset. Below that point everything scaled together and the two screens matched. Above it the cap kept growing around an icon that could not, so on a large display an icon drew at 24% of its cap where the same icon on the Edge drew at 40%, the same profile, visibly different.

  It only affected *some* keys, which is what made it read as random rather than as one bug: a key whose face is a full-bleed picture is sized as a share of the cap and was always correct, so those keys stayed put while the vector icons, emoji and small icons beside them shrank.

  Icon, title and the live value badge are now a fixed share of the cap at every size, with the small-screen minimums kept as they were. Nothing changes on a Deck whose caps were already under that size, which is most of them.

• On Linux, the app comes back by itself when the page dies under it

  Reported from Bazzite with the AppImage: the clock stopped updating, then the weather stopped refreshing, and clicking on the window turned it white with no way back except restarting Xenon.

  The two frozen readings are what identified it. The clock and the weather run on two separate timers that share no code; both stop only if the engine running them is gone. On Linux the page is rendered by a separate WebKit process, and the shell survives its death, so the window keeps showing the last frame it was handed, looking perfectly alive, until something forces a repaint and there is nothing left to paint it.

  Xenon did two things wrong there, and neither was the clock. It never recorded the event: the crash diary behind Tray → Open crash log carries problems in Xenon's own process, and a dead render process is not one, so the single event explaining everything the user saw left no trace anywhere. And it did nothing about it, which is why restarting by hand was the only way out.

  Now the reason WebKit gives, crashed, out of memory, or stopped deliberately, goes into that diary, and the page reloads itself a moment later. If it dies over and over Xenon stops retrying rather than flickering forever, and says so in the diary. Windows and macOS already recover from this on their own, so this is Linux only.

  This is the symptom, not the cause; the diary is what will tell us the cause, now that it is being written down.

• All-day calendar events stay in the Upcoming list for the whole day

  An all-day event from Google Calendar arrives with no time, so Xenon filed it at 00:00, and the list, which keeps an event until it starts, retired it one minute after midnight. Turn the PC on at nine in the morning and today's all-day events were already gone. Reported from a Mac.

  Two halves of the same omission. The importer has always known an event is whole-day and then dropped that fact on the way out; the list, with nothing to tell it otherwise, read a birthday as a midnight appointment. And the two cannot be separated: a one-day all-day event's end resolves to its own start day, so once the flag is gone there is genuinely nothing left to distinguish the two.

  The flag now travels with the event, and a whole-day event counts as current until the end of the last day it covers, not from its 00:00. It also says Giornata instead of showing 00:00, which was the one thing about it that was not true. Timed events are untouched: a 15:00 meeting still leaves the list at 15:00.

• The Media tile has a hierarchy again on a wide, short screen

  On a tile that is much wider than it is tall, the shape every tile has on a Xeneon Edge, the four pieces were laid out in a single queue: cover, source chip, track title, transport, all on one baseline. Nothing read as the important one. The SPOTIFY chip sat as a peer of the song title and shoved it rightwards, and the buttons ended up marooned across an empty gap.

  It is two blocks now. The cover anchors the left; beside it one column read top-down in the order it should be read, source, then title, then artist, then the per-app volume, and the transport alone on the right, centred against the whole block. The same order the tall tile has always used, turned on its side. The source chip is sized as an eyebrow rather than a badge, so it introduces the title instead of competing with it, and the cover takes the height the text column no longer needs instead of leaving the bottom third of the tile empty.

  Only that shape changes. The tall and narrow tiles are untouched.

Documentation

• FEATURES.md was sending people to look for a panel that no longer exists

  Asked on Discord by a moderator: how do you create a second dashboard page, is there a "Create new page" button, and can the current layout be copied onto it. All three already existed; the guide described none of them correctly.

  It still documented a Layout → Pages manager. Those controls moved next to the page dots some releases ago: in Layout mode, + adds a page, ✎ renames, × removes, ‹ › reorder. The section now says that, and, the actual question, how to copy a page you already like instead of rebuilding it: My presets → Save page, then tap the preset, and a saved page always comes back as a brand-new page with the same tiles in the same places.

  Two claims were also plainly wrong. The guide said every duplicated widget is a "live mirror" of its source; five of them are not, a second Deck, Browser, Remote, Discord or Custom widget is an independent instance with its own keys, address or page. Which is why someone duplicating a page to reuse a Deck setup got an empty Deck and no explanation. The Deck section now also carries the one-tap answer: "From another Deck" in the profile menu copies a whole profile in, keys and look included.

  And removing a page destroys more than the guide admitted: single tiles come back from the layout dock, but tab groups and duplicated tiles are deleted outright, a duplicated Deck takes its keys with it. Both the guide and the confirmation dialog say so now, in every language that carries it.

  Prose cannot be unit-tested, but the claims can: the mirror list in the guide is now checked against the code that decides it, so the next widget added to one has to be added to the other.

• The code-signing notes in DEVELOPER.md were out of date in the two places that would have cost money

  They recommended Azure Trusted Signing, whose individual onboarding has been paused since April 2025, and said an EV certificate clears SmartScreen immediately, which stopped being true in 2024. Rewritten against what is actually purchasable, plus the signing recipe that was proven end to end rather than guessed at: which OpenSSL PKCS#11 path works with Certum's token and which one segfaults, and why the certificate chain has to be a chain.

4.11.8 11 September 2026

Fixed

• The settings sidebar no longer squeezes its categories into a strip on a short screen

  The list of categories scrolls, and under it sits a block that does not: the support links, the update button, the platform notice and the version number. On a tall screen that is the right arrangement. On a Xeneon Edge, wide and only 720 pixels tall, the fixed half took 337 of the sidebar's 549 pixels, leaving twenty-seven categories scrolling through a window four and a half rows high. Reported from an Edge; a 1366×768 laptop had the same squeeze and nobody had mentioned it.

  On any short screen the sidebar now scrolls as one column: the categories keep their full height, the rest follows underneath. Eleven categories where there were four.

• A versioned setup that left the engine on the old version

  The .exe on the Releases page installs the app you see; the dashboard engine behind it is installed by a second step, and that step began by asking only whether an engine was already there, and stopping if it was. True on every PC that already runs Xenon, whatever version it runs. So reinstalling with Xenon_4.11.7_x64-setup.exe replaced the app, left the engine where it was, and finished happily: Windows' *Apps & features* said 4.11.7, Xenon itself said 4.11.6 with an update waiting, and running the setup again changed nothing at all.

  Reported by someone who did exactly that, twice, on our own advice, after a failed update we had told him to reinstall over the top, which was the right idea and the wrong file.

  It now asks *which* version is installed before deciding: an engine that is behind the release gets updated (settings, layouts, notes and Deck keys kept), one that is level or ahead is left alone by name and version, and a PC that cannot reach GitHub is told that rather than shown a failure.

• A setup that reported success while changing nothing

  There are two ways to install Xenon, INSTALL.bat runs from wherever you unpacked it, the setup .exe installs into its own folder, and anyone who used both ended up with two copies on the PC. Only one of them can answer on the port the dashboard lives at, and the setup could not tell the two apart: it asked whether *something* was answering, not whether *its own* engine was. So it stopped a copy it could not find, waited for a port that was never freed, started an engine that died instantly because the port was taken, saw the old copy still answering, and called the install a success, leaving the machine on exactly the version it started from. Twice in a row, with a restart in between, and no error anywhere.

  Reported by someone who had been told to reinstall over the top after the dependency fix in v4.11.6, and who had been doing it right all along.

  The setup now checks *which* Xenon holds the port. If it is another copy, it says which folder that copy lives in, stops it, and takes over; if it is a program that is not Xenon at all, it says that instead of failing silently. And it only counts an install as finished when its own engine is the one answering.

• The dashboard now actually moves onto the screen you choose, on a Mac

  Picking the Xeneon Edge, or any second display, left Xenon sitting as a window on the main screen. The panel was found, labelled “Xeneon Edge” in the picker and selected; the dashboard simply never went there, and nothing said why. Reported by the first person to run Xenon on a Mac with an Edge attached.

  Two macOS APIs measure in different units and neither mentions it: asking a screen where it is gives an answer scaled to that screen, while telling a window where to go is read in the scale of the screen it is on at that moment. With a Retina main display next to the Edge the two disagree by a factor of two, so “go to the Edge” came out as a point still inside the main display. The move succeeded, at the wrong place. Every screen Xenon can be sent to is now measured in units that mean the same thing on both.

• The app window is dark behind the dashboard, instead of white

  The web view Xenon draws into paints a background of its own underneath the page, and nobody had ever told it which colour, so it was the default, white. Any moment the page was not painting its own background, that white showed through: a flash at launch on Windows, and on macOS something that outlasted the launch. After the display slept, the page came back without repainting its background, and the white underneath showed in every gap between the tiles, which are semi-transparent, so they turned pale grey sitting on it. The whole dashboard looked like it had switched to the light theme, on a Mac set firmly to Dark. The same white flashed for an instant on every theme change, which is the clue that solved it.

  Reported from a Mac mini with before-and-after screenshots, which is what made it clear the colours themselves had never changed.

• The dashboard no longer wakes up white on a Mac

  With the appearance set to Auto, every time the display went to sleep the dark dashboard came back light, reported from a Mac mini, and reproducible on every wake.

  Auto follows the system, and the only way it had to ask on macOS was the WebView's own answer, which after a display wake is briefly “light” on a Mac that never left dark. That was enough to repaint everything, and nothing afterwards disagreed: the reliable reading Xenon already used on Windows was a registry read, and a Mac has no registry.

  It now asks the operating system itself on all three platforms, the registry on Windows, defaults on macOS, gsettings on GNOME, and asks again the instant the screen comes back rather than up to half a minute later. Where an answer genuinely cannot be had, the system's own preference is still used, but “no idea” is never read as light, which is the half the old code guessed wrong.

• A widget told to wait by Spotify is now told how long

  When Spotify refuses a read because too much was asked of it at once, it says how many seconds to leave it alone, and Xenon works that out and passes it on, the widget guide has always documented it. It was being thrown away at the last step, on the way into the widget, so widgets got the refusal without the wait and had to guess. Guessing short is the expensive mistake: retrying too early keeps the whole account in the penalty box, the user's own Spotify tile included.

• “Up next” no longer shows the same album over and over

  Playing a short album or the end of a playlist, Spotify answers the queue question by padding its reply, the tracks that are left, then the whole thing again from the top, and again. With repeat off none of that will ever play: after the last track, playback stops. Xenon was passing the padding straight through, so the Spotify tile's Up Next, and any widget reading the queue, listed the same songs several times over.

  Widgets reading the queue get the same answer as the tile, the two used to go down different paths, and the first version of this fix reached only one of them.

  The repetition is now cut. Carefully, because two of these look identical from the outside: a playlist is allowed to hold the same song twice, and a queue is allowed to play one twice in a row, so nothing is removed for being a repeat of something. What gets cut is the sequence starting over as a whole, and only when the album is *not* set to repeat, the queue is not shuffled, and the loop comes back round to the track playing right now, which is what proves it is padding rather than somebody's actual queue.

Added

• The Timer's add field folds away, and its help line only appears while you are typing

  The label box, the duration box and the line of format examples under them sat on screen permanently, used once per timer, then in the way. On a Xeneon Edge, wide and only 720 pixels tall, that band was a third of the widget, and the help line was two rows of small grey text the panel could not render legibly even with Xenon scaled to 125%.

  Reported from an Edge, with the suggestion that the whole top could collapse to a strip. It does.

  The chevron beside + folds the row to a slim + New timer strip, one tap brings it back, with the cursor already in the label box, and the choice is remembered across restarts. Escape folds it away too.

  The help line is not gone, because it is the only place the stopwatch is discoverable: an empty duration is the whole gesture. It now appears while the row has focus, exactly while you are filling it in, and is bigger and brighter than it was, then gets out of the way. The timer list gains the space.

• A Deck key can now follow a state set by any script on your PC

  Keys have always been able to show a second face, a different icon, label and colour, while something is on, but only for the sixteen things Xenon watches itself: the mic, OBS, a Home Assistant entity, a widget's published state. Anything else on the machine was invisible to them.

  Asked for by someone with an AppleScript that swaps between two audio outputs, who wanted the key to show which output was live.

  There is now a seventeenth source: Reflect a script state, in the key editor. Give the state a name, give the key its second face, and end your script, .bat, PowerShell, AppleScript, Python, anything, with one line:

  `` curl -X POST 127.0.0.1:3030/state/set -H "Content-Type: application/json" -d '{"name":"audio-out","value":"speakers"}' ``

  The key changes face the instant that runs, on the dashboard and in the Virtual Deck together. Send the same name with no value to clear it. The endpoint answers only to the machine it runs on: a web page cannot reach it, and neither can a widget.

  Widgets can follow those states too: the SDK gains a scriptStates stream, asked for in the manifest and granted by the user like any other ("States your own scripts set"). Reading only, a widget publishes states of its own with deck.states, which are declared and namespaced, so no package can overwrite a name belonging to another one or to your script.

• The date in the top bar can be shortened, too

  It always spelled the day out in full, *Friday, 11 September*, which is a lot of bar once you have made it bigger. Settings → Dynamic Island → Clock → Date format now offers *Full*, *Medium* (*Fri 11 Sep*) and *Short* (*11/09*).

  Each one is asked of the system rather than cut out of the long version, so every language gets the short form it actually uses, American English even swaps the halves, and writes 09/11.

  Widgets follow it as well. The time format beside it has reached them since v4.11.7; the date format now travels the same way (theme.dateFormat, re-pushed the moment you change it), so a widget printing a date is not the one thing on screen still spelling out the whole weekday.

• The clock and the date in the top bar can be made bigger

  Asked for by someone who wanted to read the date from across the room: the top bar offered a time format and nothing else, and the date was a fixed size no theme could touch. Settings → Dynamic Island → Clock now has two sliders beside the format, one for the time, one for the date, from 80% to 200%.

  Two sliders rather than one because the date is deliberately the quiet half of that corner: someone who wants a readable date does not necessarily want a bigger clock, and the request was for the date.

  Date size sizes the whole line the date is on, the live dot, the separator and the weather beside it come with it, or a big date next to a stock-size weather chip reads as a mistake rather than a setting. The opt-in chips on that row (now playing, vitals, widget badges) keep their own size: each is its own feature, and the widget ones were sized by their author.

  They scale whatever size your screen already draws, not a fixed number: a Xeneon Edge and a laptop start from a smaller clock than a desktop does, and both keep that proportion at any setting. A phone is left out, the top bar there has no room to give.

• The Deck's minimal finish is finally minimal

  *Personalizzazione → Base → Nessuna* takes the Deck's body away and leaves the keys floating on the dashboard, except for the title bar on top, which stayed exactly where it was. That bar belongs to the faceplate, and this is the one finish with no faceplate: a profile name, a page badge and a pencil, hanging over nothing. It now collapses with the rest of the chassis.

  Not removed, collapsed: that bar is the only way into edit mode and the only place to switch profile, so hiding it outright would shut you out of your own Deck. It becomes a thin strip, hover it, or tap it on a touchscreen, and it comes back; it stays up on its own while you are editing or picking a profile.

  Asked for from a Xeneon Edge, where the Deck sat next to a Calendar, a Player and a Timer that are all just a border and their contents.

• The Deck stops saying "1 / 1"

  The page counter in the title bar showed even on a Deck with a single page, where it has nothing to report, and duplicated the arrows and dots that already appear under the keys the moment a second page exists. It now appears only when there is somewhere to page to, on every finish, not just the minimal one.

• The Calendar's upcoming events stop splitting into columns too narrow to read

  Past a certain width the list broke into two columns, and on a wide, short panel like the Xeneon Edge, where every tile is narrow, that meant two columns of one word each: “FC Barcel…” beside “Levante - FC…”. The width it split at was the width of a whole row, not of the event name inside one, and a row spends most of itself on the dot, the padding and the time. A second column now appears only when it is wide enough to carry a name whole, so the same tile shows five full titles where it used to show ten halves.

  And if you would rather decide it yourself, Settings → Calendar → Columns now offers *Automatic*, *One* or *Two*. Requested with a screenshot from an Edge.

• Widgets can read past the first fifty followed artists

  Saved albums, playlists and Liked Songs could always be paged through to the end; followed artists and recently played could not, Spotify pages those two by a marker rather than by a page number, and there was no way to send the marker back. A widget saw the first fifty and stopped there. It can now ask for the rest, and a marker it gets wrong is refused rather than answered with the first page again, which is the version of this bug that looks like an endless list of the same names. Reported by the author of the Spotify library browser.

• Xenon is now in Windows' own list of installed apps

  It installs from a folder rather than through an MSI, and Windows had no idea it was there: nothing under Settings → Apps → Installed apps, nothing in Control Panel. The only way out was UNINSTALL.bat, back inside the folder, findable if you knew it was there, invisible if you did not.

  So people deleted the folder instead, which takes the files and leaves behind everything that lives outside them. Chief among those is the entry that starts Xenon when you sign in: Windows kept running it, found no script where it pointed, and said so in a box you can only click OK on, at every single boot, on a PC with no Xenon left on it to explain where the box was coming from. Reported on Discord by someone it had been greeting for a while.

  Installing now registers a normal uninstall entry, so Xenon is removed the way every other program is, and that route takes the startup entries with it. Already deleted the folder? The two lines that clear the leftovers are in README's troubleshooting section.

• Turn one person in a voice call up or down, from the Discord widget

  One friend twice as loud as everyone else is the oldest problem in voice chat, and Discord's own fix is buried in a right-click menu in another window. Tap someone's name in the Discord widget's call list and you get their volume and a mute that applies to you alone, they carry on talking to everyone else exactly as before.

  It is one row and no words: a speaker to silence them, a slider, the number. The name is not repeated, it is lit up in the list right above it.

  Your own name is not one of them: Discord has no per-person setting for your own account, and your levels are the microphone and output rows just above.

  Two things that look alike are drawn differently on purpose. Someone who muted their own microphone is dimmed, as before; someone *you* turned down or muted carries a mark of your own, so "they went quiet" and "I turned them down" never look like the same thing.

  Xenon has been able to do this since 4.11, but only for widget authors, through the SDK, so the only way to use it was to write a widget. Someone went looking for the setting and there wasn't one. Now there is.

• Widgets are told whether you read Celsius or Fahrenheit

  A widget that draws a temperature had no way to know which one you use, so one showing °C on a dashboard where the clock, the weather and the lock screen all say °F was wrong in a way its author could not see from their own machine. The setting is now handed to widgets at start and again the moment you change it, alongside the language.

  The numbers themselves are unchanged and always Celsius, as they have always been, what a widget gets is which unit to show them in. Converting them on the way out would leave a widget unable to tell 30 °C from 30 °F, and would quietly change what every widget already installed is drawing.

• Video rows a widget reads now say which channel they came from

  They carried the channel's name but not its id, so a widget could print the name and not make it open anything. Tapping a channel name works again, and it is the channel that *uploaded* the video, not whoever made the playlist it was read from, which is the mistake the same data invites.

• A widget can ask for YouTube's own channel order

  The subscription list a widget reads was always alphabetical, so a widget offering "YouTube order" was showing A–Z under another name. It can now ask for YouTube's own ranking, or for channels with something unwatched first, and an order Xenon does not have is refused rather than quietly answered in the default one, which is what let the wrong label go unnoticed in the first place.

• A widget can play a song without throwing away the album it came from

  Reported by the widget author who moved his Spotify browser onto the SDK: tapping a track inside an album played that track and then stopped, with the rest of the album gone.

  That was Spotify's own behaviour rather than a fault, asking for a single song *is* a queue of one song, but it is not what tapping a row in a list means. A widget can now say what the track came from, so the same tap means "play this album, starting here" and the rest follows, exactly as in Spotify's own apps. Sending it is always safe: anything Spotify cannot honour that way falls back to playing the song that was tapped, never a different one.

• The frame rate now agrees with your other overlays, including with frame generation on

  Reported by the author of a monitoring widget, with measurements: on one game with DLSS Frame Generation at x2, Xenon read about 220 frames a second while RTSS and the NVIDIA overlay both said about 155.

  Nothing was broken, Xenon was answering a slightly different question. It counted how often the game *hands a frame over*, which with frame generation is no longer how often the screen actually changes. It now counts what reaches the display, which is what everyone means by their frame rate, and the number lines up with the overlays. In the same measurements it is the closer number even with frame generation switched off.

  Widgets can also read both halves separately now, frames handed over and frames shown, because the gap between them is exactly what frame generation is doing, and a monitoring widget may want to show it.

  Xenon also picks *which* program to read the frame rate from more carefully: the window you are actually looking at, when it is producing frames, rather than whichever program on the machine happens to be the busiest. A launcher, an overlay, or a second game left running in the background could win that contest before.

• Widgets can read YouTube, and put a real YouTube player inside themselves

  The author building a YouTube widget had to run a private server of his own alongside Xenon to get at either. Both are now part of the SDK, as two separate permissions.

  Reading covers six things: the latest uploads from the channels you follow, the channels themselves, a search, a channel's videos, a channel's playlists, and what is in a playlist, with proper paging, so a widget can walk a large library instead of showing the first page and stopping. The widget names one of those and gets the answer; it never receives your YouTube login and cannot ask for anything else. YouTube gives an account a fixed budget of requests a day, shared with Xenon's own YouTube tile, so the answers are cached and a search, which costs a hundred times an ordinary read, is only made when something actually asks for one.

  The player is the other half. A widget's own frame is sealed off from the network, which is what makes installing one safe, so it cannot embed YouTube itself: it asks Xenon to place a player inside its layout, and Xenon owns it. The widget says which video and where, then plays, pauses, mutes, seeks and moves it, and hears back what the player is doing. Only one exists on a dashboard at a time, so two videos can never talk over each other; it cannot be shrunk to a size nobody would see; and it goes away with the tile, a video does not keep playing for a widget that is no longer on screen.

  Two permissions, asked for separately. Reading your subscriptions is not the same as playing a video inside a tile, and neither is the same as the existing "control your YouTube stream", which is about your own broadcast. A widget that has one still cannot do the others.

• Xenon now absorbs the Spotify bursts a widget makes

  From the same widget author, building a library browser: Spotify limits how much an account may ask for in a short window, and a widget that re-reads a page every time it redraws burns through that limit fast, a limit shared with Xenon's own Spotify tile, so the person's music stops and it looks like Xenon broke.

  Repeated reads no longer reach Spotify. Two identical reads happening at the same time share one call, and a read repeated within a few seconds is answered from memory, so redrawing, reopening a tile, or having the same widget on two screens now costs nothing. It is deliberately a few seconds and a handful of pages, not a store: your library still visibly changes, and what is playing right now is never held for long.

  When the limit is hit anyway, the answer now says how many milliseconds to wait, so a widget can wait exactly that long instead of guessing, guessing short is what keeps an account stuck. And starting playback from a widget clears what was remembered about playback, so the queue it reads straight after is the new one.

• A widget can browse your Spotify library without ever touching your account

  Widgets could already control playback, play, pause, skip, but not read anything, so anyone building a Spotify browser had to run a private server of their own alongside Xenon just to fetch a playlist. One did exactly that, and asked for the honest version instead.

  Xenon now answers a fixed list of Spotify questions on a widget's behalf: what is playing, the queue, your playlists and devices, your saved albums and songs, what you played recently, the artists you follow, the contents of an album or playlist, and search. The widget names one of those and gets the answer. It never receives your Spotify login, cannot ask for anything not on the list, and can start a track, album, artist or playlist it found, nothing else.

  Reading is a separate permission from controlling. "Control Spotify playback" is play, pause and skip; your listening history, saved music and followed artists are a different thing to hand over, so they are asked for on their own line and a widget that only controls playback still sees nothing. Two new Spotify permissions are requested at connection time for the history and followed artists; if you connected Spotify before this release, everything keeps working and only those two ask you to reconnect, and say so when they do.

• Widgets follow the language you pick, instead of the one you had when they loaded

  A widget writes its own text, and Xenon told it which language to use, once, when it appeared. Change the dashboard language afterwards and every widget on screen stayed in the old one until something reloaded it, sitting next to a dashboard that had already switched. Now they are told, the same way they are already told when you change the theme.

  Noticed while a widget author was showing a tile he had written in French: a German user would have had a French tile on a German dashboard, with nothing to explain why.

• A widget can start a game you own

  A Steam tile that shows what you played last and launches one when you tap it needed a permission that did not exist: Xenon could already start a game by its Steam id, but only from a Deck key, never from a widget. Now it is a permission like any other, listed as "Launch a Steam game" and off until you approve it.

  It is its own permission rather than a wider version of "open web links", which is the point: those two look similar and are not. A widget that may open a link should not silently gain the ability to start programs, least of all one you already approved for links months ago. A widget names a game id, digits, nothing else, and never a command.

• Widgets can keep artwork instead of downloading it again every time

  A widget showing album covers, game art or video thumbnails had nowhere to put them: the only store it has caps a single value at 16 KB and the whole thing at 256 KB, and an image encoded as text is bigger still. So every cover was fetched again on every redraw, over a bridge built for small messages. Asked for by someone building exactly those widgets, who had already written this for himself and told us where his own version fell short.

  Pictures now come down a route Xenon already had for map tiles, which hands them to the widget as an ordinary image instead of squeezing them through that bridge, and the ones worth keeping are written to disk so they survive a restart. Nothing about what a widget may reach changed: the address still has to be one the widget declared and you approved, and the same protections apply.

  The part that took the work is the forgetting. A cache that only ever grows is a slow leak, and left alone this one would have been a big one: every album played and every game in a library is another file. So there is a ceiling per widget and a ceiling for all of them together, whatever is thrown away is really deleted rather than merely forgotten, an hourly pass removes anything left behind by an interrupted write, what goes first is what you have looked at least recently, and uninstalling a widget takes its pictures with it. A cover is also re-checked after a week, because an image can quietly change behind an address that stays the same.

4.11.7 5 September 2026

Added

• Widgets can read clock speeds and your frame rate

  Asked for by someone building a monitoring widget who had run out of numbers to draw: Xenon knew the CPU and GPU clocks and the frame rate in a game, and none of it reached the widgets people write.

  Four readings join the system data any widget can already be granted, CPU clock, GPU core clock, GPU memory clock, and frames per second. There is no new permission to approve: a widget you have already allowed to see system data can use them, and one that has not been allowed still sees nothing.

  They cost nothing to collect. Every one of them rides a reading Xenon was already taking on the same tick, so a dashboard showing them does no more work than one that does not, and the rate everything arrives at is unchanged, the sensors underneath are the expensive part, and speeding them up is a decision that belongs to you in Settings rather than to a widget.

• A stopwatch, in the same tile as the timers

  Leave the duration empty and press +: instead of a countdown you get a clock that counts up, for measuring how long something actually took. Pause, resume, reset, keep and delete are the buttons you already know, because underneath it is the same clock, only running the other way.

  There is no second button to learn, and the duration field carries the whole vocabulary: 5 is a countdown, empty is a stopwatch, and +5 is a stopwatch that chimes every 5 minutes. That last one arrived from the same thread, where an "interval timer" turned out to mean exactly this: it counts up and sounds an alert at intervals, for stretching breaks. It is not a third kind of clock, so it costs one character rather than a control.

  A stopwatch never rings for having finished, since it has no end to reach, and it interrupts you only if you asked it to. The alert reaches your phone the same way a finished timer does, a missed hour of them wakes you to one notification rather than four, and pausing or resetting silences it. A small mark before the name tells a stopwatch from a countdown when both are paused, and a chiming one shows how often beside it. There is a Deck action, with the interval as an optional field, and the assistant reports the time spent when you ask what is running.

  Asked for on Discord, alongside an interval timer that is deliberately not here yet.

• You choose what the Upcoming list shows

  Settings → Calendario now has two controls: how many events the tile lists (3, 5, 8 or 10) and how far ahead it looks (no limit, 7, 14 or 30 days).

  This came from a request for "a custom date range", saying the widget shows the next two weeks. It never did: it took the next five events and their dates fell wherever they fell, so a quiet fortnight put an eleven-day chip on screen and that looked like a rule. The count was the only limit there was, and it was not adjustable either. Now both are, and the days are counted the way a person counts them, a 7-day horizon set at 11pm still includes an event seven sleeps away at 8am, which counting 7×24h would have dropped.

  Leaving both alone keeps exactly what Xenon did before: five events, no horizon.

• Voicemeeter, from the inside

  Windows shows Voicemeeter's virtual cards like any other sound device, so Xenon could already pick one and set its volume. What it could not reach was anything *inside* the mixer, which is the part people actually bind to a key: the gain of one strip, its mute, and the A1/A2/B1/B2 buttons that decide where each source goes. Asked for on Discord by a supporter running Potato, with three other tools doing it for reference.

  There are now seven Deck actions under Voicemeeter: mute a strip, strip volume, send a strip to a bus, mute a bus, bus volume, press a macro button, and one free-form action that sets any parameter the mixer has. That last one is not a leftover: every control in Voicemeeter is a named parameter, so the EQ, the compressor, the gate, the patch and the recorder are all reachable today without waiting for a release per knob.

  The strip and bus pickers are filled from the mixer that is actually running, so the list is as long as your edition and no longer: Voicemeeter has 3 strips and 2 buses, Banana 5 and 5, Potato 8 and 8. A key stores a bus by its label (A1, B2) rather than by its number, because the number behind a label moves between editions, B1 is bus 1 on Voicemeeter, bus 3 on Banana and bus 5 on Potato, and a key that stored the number would quietly start muting a different output the day its owner upgraded. An index the running mixer does not have is refused where you can see it, rather than written into nothing.

  Nothing is loaded on a machine without Voicemeeter, the category is not offered there at all, and volume set on a key is clamped to the fader the mixer really has (−60 to +12 dB) instead of being silently clamped later.

  A key that cannot run says why in your own language: Voicemeeter not installed, installed but not open, a strip or bus your edition does not have, a value it will not take. Before this the toast showed the raw code.

  Installed widgets can use it too. voicemeeter is a new SDK permission, so a widget you install can drive the mixer once you grant it, and a new voicemeeter data stream pushes the live state, mute, gain and the routing flags per strip, mute and gain per bus, so a widget can draw real faders instead of blind buttons. The free-form parameter action is deliberately not part of that grant: it can name anything the mixer has, including "shut down Voicemeeter", and that stays a Deck-key privilege. The stream is read from the mixer's own change flag and only while a dashboard is open, so it costs nothing when nobody is looking.

• Xenon asks for support once, and only once

  There has been a donate button since the beginning, in the app, on the site, on GitHub, on Discord, and it has never asked for anything, so only people who went looking ever found it. Now it asks, one time in the life of an installation, and then never again.

  It waits until the question is a fair one: thirty days after your first run and ten separate days of actually opening the dashboard. Someone who has come back on ten different days over a month has decided Xenon is useful; anyone earlier is still deciding, and asking them is asking a stranger for money. Days are counted when a dashboard opens, not when the engine starts, so a PC that runs it at logon and never gets looked at earns no credit.

  It never appears for someone who already supports the project, never over a voice session, the lock screen, a game or an Ambient scene, it simply does not come up that day, and it makes no sound and blocks nothing. It is the same small card as the Discord invite, in the same corner, dismissed the same way. And because "once" has to mean once, the answer is kept on your PC rather than in the browser: clearing your browsing data will not bring it back.

  The card says what is true, one person writes this, in their spare time, with no ads, no investors and no paid version, and that is not changing, and then what supporting gets you: the exclusive themes and widgets, a role on Discord, your name on the site. A few euros a month is the offer, with a one-off beside it; until now the only framing was "buy me a coffee", which is a one-off by its nature.

  There is also a third, quieter button: *I already support Xenon*. Xenon can only see supporters who have redeemed their pass in the app, so somebody who gave and never claimed their perks would otherwise be asked for money they already send. That button silences the card for good and takes them to where they can finally claim what they paid for.

Fixed

• Apple Music album art now appears, and the album is back on its own line

  Reported on GitHub with the payload attached: on Windows, Apple Music tracks showed no cover at all, and the artist line read “Artist, Album” with both mashed together. Spotify was unaffected.

  The cover was being fetched correctly every time and then thrown away by a comma. Apple Music describes its artwork with a *list* of equivalent format names, and Xenon passed that list on whole, but in the address a picture travels in, the first comma ends the format name, so the browser read everything after it, the picture included, as ordinary text and never turned it back into an image. A perfectly good photo, lost to punctuation.

  That one comma cost the cover twice: because a broken address still counts as *an* address, it also switched off the backup that looks the artwork up online, and the accent colour Xenon takes from the cover quietly gave up on every track. All three work again, and the cover you get is the real one from the app rather than a lookup that might find the wrong release.

  Apple Music also puts the album into the artist field and leaves the album blank. It is now split back into two, at the first long dash, which is where Apple joins them, the artist always coming first. Only when the app sent no album of its own, and only for Apple Music: elsewhere an artist whose name contains a long dash is left exactly as it arrived.

• The Twitch widget's live list now refreshes on its own

  Reported on Discord: “I can't refresh the live channels, channels that went offline are still shown as live, and channels that just went live don't appear.”

  The widget checks in with Twitch every minute and always has. It just never asked for the list again: it fetched the channels once when the tile appeared and then only ever re-used what it already had, so the timer ran for hours with nothing to do. Whoever was live when you opened the dashboard stayed lit until you switched tabs or reloaded the page.

  The list is now genuinely re-read each minute, quietly, no spinner blinking behind you, and if a check fails the list that was right a minute ago stays on screen instead of being replaced by an error. Search results are left alone, since those are what you asked for rather than a live feed. Widgets granted the Twitch watching data get the same fix for free: they were being handed the same frozen list.

• A Browser tile no longer freezes when the dashboard is open in two places at once

  Reported on GitHub with a camera stream that stopped after a while: with the dashboard on the Xeneon Edge *and* in a browser window on the PC, one of the two Browser tiles held its last picture and never moved again. Closing either dashboard brought the other back to life, and after a restart the roles could swap.

  Each screen opens its own page for the tile, on purpose, they can be different sizes, so they cannot share one. Those pages were opened as tabs of a single window, and a browser only draws the tab in front. The tile's picture comes from a stream of frames, and a page nobody is drawing produces none: whichever screen opened last took the front and the other simply stopped receiving. It never looked like an error, because there was nothing to report, only a picture that had stopped being replaced.

  Every tile now gets a window of its own, so no screen can be behind another. Measured on the way in and out: two tiles on a page that redraws constantly went from 0 and 23.7 frames a second to 24.0 and 23.8, and three screens at three different sizes now hold their own rate through a resize.

  It also explains the half-height picture in the same report. A frozen tile keeps showing whatever it was showing, so a tile resized in the meantime still displayed the page laid out for its old size, which is why hiding and showing the toolbar appeared to be the cure, while reloading the page did nothing at all.

• Setup now says what went wrong, instead of closing on a red line

  Reported on GitHub as a screenshot of the black window with *“The term 'cmd' is not recognized”*, from a PC where that program is exactly where Windows keeps it. The list of folders Windows searches had lost C:\Windows\System32, which happens on its own when a long list is edited past the length the old settings dialog can store, or when a “debloat” script rewrites it, and setup was asking for its tools by name.

  Setup no longer asks. It reaches Windows' own tools where they live, and each setup script puts that folder back on its own search list for as long as it runs, changing nothing on the PC. Four more ways in used to end the same way, in a window that closed over the reason: a declined administrator prompt exited without a word, a missing PowerShell reported a file not found three times, running the installer from a network folder carried on from the wrong place, and double-clicking it inside the downloaded .zip, where Windows unpacks that one file alone, reached a check that had nothing to say about zips. Each now names itself and the fix.

  A last one that was a genuine crash rather than a bad message: a Windows user name containing an apostrophe, which is allowed and does happen, broke the line that asks for administrator rights.

• The time format you chose is now used everywhere, not only on the clock

  Settings → Clock → Time format has been there for a long time and reached exactly two places: the dashboard clock and the lock-screen clock. Every other hour Xenon printed asked the *language* instead, so if you set 24-hour and read English, the clock said 21:30 while the calendar right beside it said 09:30 PM.

  Eleven places were ignoring it: the calendar and its Upcoming list, the agenda, the Ambient scenes, the lock screen's event list, the football fixtures, the stock ticker, the Discord widget and the weather timestamp. They all go through one shared formatter now, and a test fails the build if a twelfth ever decides for itself.

  Reported on Discord by Piotr as a missing option on the Calendar widget. The option already existed; it was simply not being listened to.

• The Deck action list opens when you ask it to, and closes when you pick something

  Reported on macOS: pressing "+ Add action" in the key editor made the list of actions appear on its own, and choosing an option from it left the list open instead of collapsing.

  One press was producing two clicks. Pressing "+ Add action" rebuilds the whole list of actions from scratch, right there inside the handler for that press, and when the thing under your finger is replaced mid-click, the browser fires a second click at whatever has taken its place. What had taken its place was the dropdown that rebuild had just created, so it opened itself. Picking an option rebuilds the list the same way, so the second click re-opened it the instant it closed: from the outside, a list that will not collapse.

  A control now ignores a click belonging to a gesture that happened before it existed, which is exactly what those stray clicks are, they carry the timestamp of the press that created the control. No delays and no guessed thresholds: a click from before something existed was not aimed at it. Deliberate clicks, keyboard use, and anything driving the control from code all behave exactly as before.

  Reproduced against the real dashboard in a browser before it was changed, and verified there afterwards, in both engines.

• A fix to the updater now helps the update that carries it, instead of the one after

  This is the reason the entry above ends with "reinstalling once will fix it", and it should not have needed to.

  An update is applied by the copy of the updater already on your PC, it has to be, because the new one arrives in the middle of the job. So a repair to that updater has always taken effect one update late: the people it was written for could not receive it by updating, because the step it repairs is the step that fails for them. That is exactly what happened with the dependency failure above.

  There is one moment where the work can safely change hands: after the new files are in place, which is when the new updater is sitting on disk, and before anything that depends on what the first half did. At that point, if the update brought a *different* updater, it is handed the rest of the job.

  It is built to be boring. If the updater is unchanged, almost every update, it is one comparison and nothing else happens. Exactly one process is ever in charge: the first waits for the second rather than letting go, so there is never a moment with two of them running, or none. The second announces itself before it does anything at all, so "it took over and something went wrong" can never be confused with "it never started", and if it truly never starts the first one simply carries on as it always did. And it runs with the permissions already granted, so no second Windows prompt can appear.

• A Deck key now works with an app or folder whose name has spaces in it

  Reported on a Mac: an "Open app" key pointing at an application with spaces in its name did nothing, and renaming the application to remove them made the same key work.

  Launching was never the problem. The trouble is what ends up in the field. The ordinary way to get a path on a Mac is to drag the file into Terminal, and what that writes is /Applications/Epic\ Games\ Launcher.app, every space escaped, because it is meant for a shell. Some copy tools wrap the whole thing in quotes instead. Either way the text names a file that does not exist, so the key fails forever while the field looks exactly right, and the only workaround is a name with no spaces in it.

  Windows has had the matching fix for a while: paths copied from File Explorer arrive wrapped in quotes, and those get stripped. The Mac and Linux equivalent was missing, and it is a little more careful, because a backslash and a quote are both legal in a filename there, so it is settled by the disk rather than by the characters. A path that already points at something real is never reinterpreted, and a rewritten one is only used when it actually exists. It applies to app keys, file and folder keys, and script keys alike.

• Updating no longer fails on the machines where installing was fixed in v4.11.6

  Reported with a screenshot of "dependency installation failed", and it turned out to be a bug we had already found once and only half-fixed.

  One of the packages Xenon depends on ships a guard that deliberately fails installation unless a particular tool is doing the installing. On most PCs a helper quietly satisfies that guard and nobody notices. On a PC missing one specific folder, it only exists once you have installed something globally, and cleanup utilities delete it, the helper itself cannot start, the guard fails, and the whole install is aborted half-written. That is the broken install v4.11.6 fixed, by telling the installer to skip those scripts entirely.

  The updater was never told the same thing. So on exactly those PCs a fresh install worked perfectly while every in-app update walked into the same wall, failed at that step, and rolled back cleanly, which made a bug we shipped look like something wrong with one person's computer. Both now install the same way, and the updater also runs the one build step that skipping scripts skips.

  If this is happening to you, updating into this version will not fix it, reinstalling once will. The update is applied by the copy of the updater already on your PC, so the corrected one only takes effect from the update *after* you are running it. Download this release and run its installer over your existing setup: it keeps your settings, widgets and layout, and it is the last time this is needed.

• A failed update now tells you what actually went wrong, in the words of the thing that failed

  Reported with a screenshot of the whole message we had: *"The update could not be applied and your previous version was restored (dependency installation failed)."* True, and useless. That same sentence appears whether the PC is offline, sitting behind a company proxy, out of disk space, or has an antivirus holding a file open, four situations with four different fixes, and no way to tell which one you are in.

  Part of an update is fetching the pieces the new version needs, and that job is done by npm, which prints exactly what went wrong. It printed it to a window nobody sees: the step was run with its output going nowhere at all. So we had the name of the stage that failed and threw away the reason it failed, on the one screen where the reason was the entire question.

  It is kept now. The full transcript is saved next to the update log, its last lines go into that log, and npm's own one-line summary is shown right after the reason on the failure dialog, untranslated, because those are a tool's own words and they are what you paste to someone who can help. If the recovery afterwards hits its own trouble, the message still describes the failure you are looking at rather than the recovery.

• Deck keys that outlived their tile can be brought back, instead of only thrown away

  Following the reset above: when a dashboard is replaced, the Deck tiles on it go too, and every key programmed on them becomes unreachable while still sitting safely on disk. The reporter went looking and found a profile list holding one default and several same-named copies, none of them the one he had built.

  Three rules had grown up around this, each sensible on its own. A leftover deck configuration is only deleted automatically when it is empty, deliberately, because keys are data and data is not thrown away quietly. Leftovers are hidden from the profile menu, so a deck you removed does not haunt the list of the ones you kept. And the profile menu offered exactly one thing to do about them: a button that deletes them.

  Together those made a trap. The keys were kept, hidden, and the only action available was the one that destroys them. The profile menu now lists them, under "From a Deck no longer on your dashboard", and tapping one copies it into the deck you are looking at, which is the same one-tap move that already existed for a profile on another deck. Each row shows how many keys it holds, because after a reset the list routinely holds two profiles with the same name, one empty and one with the work in it, and the number is the only thing that tells them apart. It is not hidden behind edit mode: recovering something you lost is not editing a layout.

  The delete button is still there, and now says what it costs, how many programmed keys go with it, and that they do not come back. When there is nothing to lose it stays as calm as it was.

• Xenon now notices when something stops it starting with Windows, and repairs what it can

  Reported by someone whose dashboard kept going quiet: *"something keeps disabling the requirements in task scheduler."* He had spent days reporting features that had stopped working. They had not: the engine behind them was simply not running, and nothing anywhere said so.

  Xenon starts through an entry in Windows' own Task Scheduler, and the installer sets three things on it on purpose. Start while on battery, because otherwise unplugging a laptop closes the dashboard and looks like a crash. Do not stop when the charger comes out, for the same reason. And no time limit, because Windows otherwise ends the task after three days, a program meant to run all day, stopped by a stopwatch. Those three were checked once, at install, and never again.

  The engine now checks its own startup entry shortly after it starts and every few hours after that. Those three conditions are ours, so if something has changed them they are put back, and you are told it happened, the app changed a setting on your PC and should say so. Whether the entry is switched on is not ours: Windows offers you that switch in Task Manager, and flipping it back behind you would be overriding a real choice. So that one is reported instead, and it stays on screen until you dismiss it, because it is the one that costs you the whole next session: it says Xenon will not start when you next sign in, that Xenon never switches itself off, and exactly where to turn it back on.

  A machine with no such entry, a developer checkout, a portable run, a Mac, is left entirely alone and says nothing.

• A settings save can no longer replace your whole dashboard with the factory one

  Reported on a Mac after an update: the layout back to the factory default, the Deck tile gone with it, and the theme unchanged, the connected Google Calendar still there, every installed widget still installed, and the settings file itself sitting where it belongs. One thing in that file had reverted while everything beside it survived untouched.

  Xenon stamps the saved layout with a format number, so that a build which changes the layout format can replace an incompatible one instead of drawing it wrong. That is a one-time step on an upgrade, but the check had been written into the routine that runs on *every* save, and it read the number off the arriving save rather than off the file on disk. Any save that did not carry it therefore read as "format 0": the entire dashboard was replaced by the default, every other setting in the same save was kept, and the file was then re-stamped with the current number, so nothing was left to find afterwards.

  A save that does not carry the number now inherits the one already stored, the same rule this app already applies to paired-device access, your transfer folder and several other settings that only one screen knows about. An absent value means "this writer does not model it", never "set it back to zero". What can legitimately be old is the layout on the disk, and that is what the upgrade step is now judged against.

• And when that upgrade step really does run, your old layout is kept

  It was the one destructive thing in Xenon that was neither confirmed nor reversible: it happens at startup, without asking, and you find out by looking at your screen. The layout it replaces is now copied to dashboard-layout.backup.json in your Xenon data folder before anything writes over it, the startup log says so and says where, and the pictures you had set on your tiles are protected from the cleanup that would otherwise sweep them on the next save, a backup that restores the tiles and loses every image on them is worth less than it looks.

• "Reset all settings" now asks first, and says what it takes

  Mentioned in passing on Discord by a supporter, while he was helping us debug something else: *"yesterday I reset Xenon by error and lost everything."*

  It fired on a single click. No dialog, nothing to cancel, and from the accent-coloured button at the bottom of the settings panel, directly under "Restart Xenon", whose own hint promises in so many words that nothing will be lost. The harmless button was the one asking for confirmation; the irreversible one was not.

  "Settings" also undersold it. The dashboard layout and the calendar feeds survive. What does not: the widget assigned to every tile and the permissions you granted it, your list of installed content, your saved page presets, and every custom theme, background and Ambient scene you made. That is why the person who pressed it did not describe the result as losing his settings.

  It now asks, in the destructive colour, with Cancel focused rather than the button that does the thing, and the question lists what goes and what stays, including the part that matters most afterwards: your widgets are still installed on the PC and can be assigned back. A line under the button says the same before you ever press it.

• A widget could install, report success, and then not exist

  Reported by a supporter who installed the same widget three times: the Store said "Installed" each time, three receipts were recorded, and the tile picker never listed it. He went further than we could have asked, he opened the engine's own package list in a browser and searched it for the name. Not there either: not as a widget, and not as a package that had failed to load. Then he put the folder in place by hand, with exactly the same result.

  The engine loads a bounded number of installed packages. Reaching that number stopped the scan dead, and every package past it was installed, valid, sitting on disk, while being absent from the widget list, absent from the failed-to-load list, and therefore absent from the picker, the palette and the Store's idea of what you own. Nothing was logged, nothing was counted, and the only visible symptom was a list that was shorter than the truth, which is indistinguishable from a smaller collection. Folders are read in name order, so it was always the same alphabetical tail that disappeared, which is why one particular widget was unfindable while everything else worked.

  The limit is now far above what a real collection reaches, so this stops happening at all. And reaching it is no longer silent: the engine counts what it left out and the widget picker says how many installed widgets are beyond the limit, on the same panel where you are looking for the one that is missing.

• The engine now writes down which settings store it started on

  Reported on a Mac: "the visual layout is back to the factory default, after an update the screen was loaded with many different widgets." Three different things produce that screen. The saved layout was replaced; the saved layout was never read; or this installation is reading a different data folder than the one the layout is in. From the dashboard they are identical, and nothing on the machine said which had happened, so there was no way to answer the question, and no way to tell the person whether rebuilding their dashboard by hand was the right move or the one thing that would destroy it.

  The engine knows: it reads settings.json a second after it starts. It now writes one line about it into the same server.log the rest of the startup story is already in, the file was loaded (with its revision and store id), or there was no file there and this run begins from the factory defaults. The full path is part of the line, because a second installation pointed elsewhere is the other way that screen appears, and the log is then the only place that says so.

  And the failure in the middle is no longer silent. A settings file that exists but cannot be read, a permission the system took away, a half-copied folder, used to be swallowed whole: the engine ran on factory defaults with the transfer limits, the network binding and the lighting configuration all unapplied, while every attempt to save was refused for the same reason. Factory defaults you cannot even change, with nothing said anywhere. It is now the loudest line in the log, and it ends with the advice that matters at that moment: do not re-create your setup yet, the real one is still on disk.

• A Deck key that fails now tells you why, instead of only flashing red

  Reported by someone setting up an "Open app" key: the path was a real application, correctly spelled, and pressing the key flashed red and did nothing else. There was no way to tell a path that does not exist from one the system refuses to launch from an app that simply would not start.

  The reason was always there. The dashboard asks the engine to run the action, the engine answers with both a yes/no and a reason, and the dashboard read the answer, kept the yes/no, and dropped the reason on the next line. It now shows it: the key still flashes, and a short message names what went wrong. A reason we have no wording for appears as its raw code rather than as nothing, because that code is what belongs in a bug report.

  Repeats of the same message collapse for a few seconds, so a slider being dragged against a broken action cannot bury the screen, but a *different* failure still comes through straight away.

• An install that cannot update itself now says which part is missing

  Following the report above: the status page answered supported: false and stopped there, which told the person holding the machine, and us, equally little. Three different situations produce that answer and each has a different fix.

  It now names the one in effect: a developer checkout, an operating system with no applier, or the applier script itself missing from the install. That last one is worth knowing about, because a PowerShell script whose job is to copy files into the install folder is exactly the sort of thing an antivirus quarantines, and a quarantine survives reinstalling, which is why the app can look permanently stuck one version behind. The reason travels with the failure message too, so it can be read off the screen without opening anything.

• The empty artwork box no longer claims nothing is playing

  Reported with a screenshot of the Playback tile: the source, the track, a running position and working transport buttons, and, where the cover goes, the words "No Media".

  That box is only ever visible when a track has no picture; a cover hides it the instant one loads. So it had exactly one thing to say and said something else, which is how an ordinary missing cover reads as a broken player. It now says "No artwork", and it says it in your own language, it was the one string in that panel written straight into the markup, so it had stayed English everywhere.

• On a Mac, a Deck key that opens an app now works with the path macOS shows you

  Reported by someone trying Xenon on a Mac: folder keys and URL keys worked, and every "Open app" key did nothing.

  macOS hides the .app extension. Finder says "Helium", Get Info says "Helium", the Applications folder says "Helium", so the path you type is /Applications/Helium, which is not an app and not a file. The key was refusing it, correctly and silently.

  It now completes the name when the bundle really is there. /Applications/Helium finds /Applications/Helium.app and launches it. Nothing else opened up: the completed path still has to be a real .app, a name that already carries an extension is left alone so a document can never become an app, and Windows and Linux keep exactly the rules they had.

• An update that cannot be applied now says so, instead of restarting the app and changing nothing

  Reported with a screenshot: "Update available · v4.11.6" sitting over "Xenon v4.11.5", and pressing Update relaunched the app to exactly the same pill.

  Xenon is two pieces, the shell your PC launches, and the dashboard engine behind it, and the version you see is the engine’s. The updater asks the engine first whether it can replace itself. It already handled the engine not answering at all, but when the engine answered "no" it quietly skipped that half and updated the shell alone: a download, a restart, and the same version on screen, which from the outside is a button that does nothing.

  It now stops there and tells you the installation cannot update itself, with the reason, instead of restarting into the same screen. Reinstalling is deliberately not offered as the cure: the setup script bails out the moment it sees a backend already running, so running it over a working install replaces the shell and leaves the dashboard exactly where it was. Nothing else about the flow changed, an installation that can update itself never reaches this path.

• A widget that installs but does not load now says so, instead of just not being there

  Reported by a supporter who installed Workload, saw "Installed" in the Store, then typed its name into a tile’s widget picker and got "No widget matches this search."

  The two surfaces were reading different things. The Store answers from the install receipt; the picker lists what the engine accepts when it rescans the widgets folder. A package whose files land but whose manifest fails that scan is installed and invisible at the same time, and the failure looked exactly like a search that found nothing.

  The engine had been reporting those folders all along, one entry per folder, each with a reason, and the dashboard fetched that list, cached it, and never showed it. It is now under the picker, naming each package and why it was skipped: a missing manifest.json, one that could not be read, a missing entry file, or a widget built for a different SDK version. A reason we have no sentence for still appears as its raw code, because that code is what belongs in a bug report. The notice sits outside the search filter on purpose, the moment it matters is when a search has just emptied the list.

4.11.6 28 August 2026

Added

• Pin the voice channels you actually use to the top

  Until now the Channels tab listed them in whatever order Discord gave, so the one you join every evening sat wherever it happened to sit, often below a server you never touch. A star on each row now pins it, and pinned channels gather into a Favourites group above everything else. Asked for on Discord.

  They stay in the order you starred them, not alphabetically, the point is to put the one you always join first, and re-sorting would take that back. A new favourite joins the bottom of the group, so pinning a second one never shifts the first out from under your finger. A pinned channel appears in the Favourites group only, not twice.

  The list is saved with your settings rather than on the machine you starred it from, so it follows you to a paired phone, the Xeneon Edge and every browser tab. That is the opposite of the tile layout, which deliberately stays per-device: how many columns suit a screen is a question about that screen, while which channels matter is a question about you.

Fixed

• The "+" drop-zone steps aside while you move or resize a tile

  In edit mode the "+" stretches to cover the page's whole empty area, deliberately, so it is an easy target, but it is a real button sitting on top of the grid, and it stayed there while you were dragging. So every gesture ended on top of it, and the click that follows letting go opened the widget palette. Reported as the "+ panel getting in the way" of rearranging and resizing.

  It now fades and stops taking the pointer for as long as a tile is being moved or resized, and comes straight back when you let go. It is dimmed rather than hidden: a target that disappears under the cursor reads as a glitch, and it is still the space you are dragging toward.

• The accent colour picker says when something else is painting over it

  Two things can take the accent over, and neither used to admit it, so the colour you picked was stored, kept, and nowhere on screen, with a picker that looked simply broken. Reported as the accent "staying yellow", which is the Pixel Retro style's own.

  Pixel Retro owns a fixed CRT palette on purpose: it is a whole look, not a colour scheme, and letting an accent through would break it. The album theme is the other one, while music plays the accent follows the cover art, which is the feature working as intended.

  Neither behaviour changes. The accent row now carries a line naming whichever is in effect and how to get your colour back, in the same place and the same style as the "covered by an active background" note that has always sat one row below. When Retro is on it is named first even if music is playing, because Retro is the one that actually wins, sending you to switch off the album theme would have changed nothing.

• When something goes wrong, the reason is now written down instead of spoken to an empty room

  The dashboard engine runs in a hidden window with no console attached, and it explains itself the way programs do, by printing. Forty-odd of those explanations exist for real problems, and every one of them was being written to nowhere. It stopped being theoretical when someone asked why their Discord notifications would not arrive: the engine had already recorded the exact reason Discord gave, and there was no way for anyone to read it. The answer existed and was thrown away.

  Warnings and errors are now copied into %LOCALAPPDATA%\Xenon\server.log, beside the reason-it-would-not-start added earlier in this release. Ordinary progress messages are not, they would bury the lines that matter. Nothing is moved: a machine with a real console still shows everything it always did. And the copy stops after 500 lines, so a fault that repeats in a loop cannot fill your disk with its own complaint.

• Xenon tells you a Discord re-link is needed as soon as you ask for it, not after the wait

  Turning on "Mirror notifications on the dashboard" after Discord was already connected did nothing visible, then eventually showed a warning saying the permission was missing. People reasonably tried disconnecting and reconnecting, which cannot help: Discord only asks for the notification permission when you link the account, and once an app is authorised it hands back the permissions it already gave rather than asking again. The one thing that works, removing Xenon under Discord → User Settings → Authorizations and linking again, was only mentioned after the failure had happened. Reported on Discord.

  The stored connection now remembers which permissions Discord actually granted it, so the note appears the moment you turn the switch on, with the steps that work. Nothing changes for a connection that already has the permission, and a connection made before this release is left alone rather than warned about on a guess, those still get the old after-the-fact notice if the permission really is missing.

  The English text shown when a translation is unavailable said the opposite, "disconnect and reconnect once", which is the advice that fails. It now matches the translated one.

• An install can no longer be stopped by a library that refuses to be installed

  This is the step before the one below, and it is where the broken install actually came from. One of the dashboard's libraries, msedge-tts, ships a guard that runs before it installs and is designed to fail unless the installer is a particular tool that Xenon does not use. On most machines that guard quietly passes. On a machine missing the %APPDATA%\npm folder, a folder that only appears once you install something globally, and that cleanup tools delete, the guard cannot even run: it errors out, npm gives up on the whole set of libraries part-way through, and what is left on disk is the half-finished install the entry below describes.

  The setup now installs the libraries without running any of their setup scripts. Nothing is lost by that: one library has no such scripts, the guard is the only one the second has, and the third's, the one behind RGB control, never delivered anything in the first place, because its compiled part arrives as an ordinary download picked for your version of Windows. Xenon's own post-install step, which the same switch would have skipped, is now run explicitly instead of being left to npm.

  It is also simply the right thing for a setup running on someone else's PC. The scripts a library can ask to run at install time are arbitrary programs, and Xenon needs none of them.

• The setup now notices when a library is only half there, and repairs it

  This is the cause behind the install that never finishes: the setup checked for the dashboard's libraries by looking for their folders, and a folder is not a library. An npm install interrupted part-way, a window closed, a connection dropped, an antivirus holding a file while it was being written, leaves the folders behind with nothing usable inside them. The setup saw the folders, reported "dependencies already installed", listed every component as OK, and skipped the repair. The engine then failed to start on every single launch, for the exact library that was never finished.

  That is what the loop was made of. Nothing was wrong with the app's diagnosis and nothing was wrong with the setup's: they were asking different questions and both answering honestly. Running the setup again could never help, because the check that decided there was nothing to do gave the same wrong answer every time.

  All three places that ask now ask Node itself whether the library loads, the same question the engine asks when it starts, so the two can no longer disagree. That covers the check before installing, the verification afterwards, and the component summary at the end, which is also what decides whether the automatic retry runs. A half-written library is now reported as missing, reinstalled, and verified.

• When the engine will not start, it now says why

  Some fresh installs land in a loop with no way out: the app shows "Xenon isn't finished installing", you press "Try setup again", a console opens and reports that everything is already installed, you press Enter, and the same screen comes back. Restarting the PC changes nothing. Reported on Discord.

  Both halves were telling the truth. Everything *is* installed; it is the start itself that fails. The dashboard engine is launched by a hidden window with no console attached, so when it died it died completely silently: no message, no file, nothing in Event Viewer. The setup then found every file where it belonged and had nothing to report either. The one fact that would have ended the loop, the error node printed as it exited, was thrown away by design, every single time.

  The engine now keeps a log of its own start, at %LOCALAPPDATA%\Xenon\server.log, beside the setup log that arrived in v4.11.5, with the run before it kept as server.log.1. It records that it started, that it reached the point of listening, and, if it failed, what the error was and what it usually means, a dependency that never finished installing, another program already holding port 3030, a permission or antivirus refusal. That file is what to attach to a bug report.

  The setup has stopped being cheerful about it too. When it starts the engine and nothing answers, that was reported as "the server may still be starting", in yellow, and the script ended successfully, which is what made running it again look like the next thing to try. It now says plainly that the install is fine and the start is what failed, prints the last few lines the engine wrote, and points at the log.

• A dashboard set to a single column can be edited again

  Choosing "Single column" under Settings → General → Tile layout took the layout editor away with it: no way in from the top bar, and no controls on the tiles. Adding a widget, hiding one, moving one to another page, all gone, on a screen with a mouse and a full top bar sitting right there. Switching back to Grid was the only way to change anything. Reported on Discord.

  The single column was built for a phone, where hiding the editor is the right call: a 24-column drag is not a thumb gesture. When v4.11.5 turned that layout into something you can *choose* on any screen, the phone's whole treatment came along with it, the compact top bar, the thumb dock, and the missing editor, because one answer was doing two jobs. Picking how many columns you want is not the same as telling Xenon what kind of device it is running on.

  Those are now two questions. The setting decides the columns; the screen decides everything else. A monitor set to a single column keeps the top bar it always had, the way into the editor included, while a phone is unchanged in every respect.

  Inside the editor, the split is the same one. Dragging a tile and pulling its corner are the only things a stacked view genuinely cannot offer, the tiles are drawn one under the other rather than at their grid positions, so a drag would move a tile somewhere you cannot see it. Those two are refused. Everything else works exactly as it does on the grid: the "+" opens the widget palette, tiles can be hidden or sent to another page, presets save and load.

• A screen mounted vertically can resize its tiles again

  On a vertical mount that stays on the grid, a tile could be made narrower a column at a time but barely shorter at all: the vertical handle moved in enormous steps and then stopped, at a tile roughly half the height of the screen, refusing to go smaller. It read as though only the horizontal direction worked. Reported on Discord.

  The two directions were not the same kind of thing. Across, the dashboard is always 24 columns, so it has 24 stops on any screen. Down, there was no fixed number of rows: the dashboard used however many rows your layout happened to occupy and stretched them to fill the height. That is right on a wide screen. On a tall one it is not, because there is one layout shared by every screen you own, so a vertical panel was drawing the same handful of rows built for a wide screen over three times the height. On a rotated 1440x2560 monitor that made a single row 300 pixels tall, and the smallest allowed tile is four rows: 1200 pixels, half the panel, to the pixel.

  On a vertical screen the extra height now buys more rows rather than taller ones. The same monitor gets 27 stops instead of 8, and the smallest tile drops from half the screen to about a seventh of it. Tiles keep the size they have on your other screens instead of being inflated to fill, and what is left below them is real grid: you can drag a tile down into it, or stretch one to reach it, where before there was a hard stop at the last row.

  Nothing changes on a screen wider than it is tall. The Xeneon Edge, an ordinary monitor and a resized browser window all keep the sizing they had, a row on the Edge measures 73 pixels, comfortably under the ceiling this adds, so it cannot be affected by it.

• "Don't show again" now means it, on the two cards that greet you at startup

  The What's New panel and the Discord invite card each carry a button that is supposed to silence them for good, and for some people it did nothing: both were back at the next boot, every boot, with the button already pressed. Reported on Discord.

  Neither card was ignoring the click. Both flags were kept in the browser's own storage for the dashboard's address, which sounds like the obvious place until you notice what shares a switch with it. "Clear cookies and site data when you close all windows", a setting in Chrome and Edge, with an equivalent in Firefox, that plenty of people turn on and never think about again, takes the dismissal with it at every shutdown, as does any cleanup tool, as does a private window. The card then came back exactly as it does for someone who has never seen it, because as far as Xenon could tell that is who was looking.

  The same storage is also per-surface, not per-user. The native app and a real browser tab are separate stores even though the address is the identical 127.0.0.1:3030, so anyone running both had to dismiss each card twice, in two places, with nothing on screen explaining why the first time had not counted.

  Both flags now live with the rest of your settings, in a file on the PC. That makes them survive any browser cleanup, and it makes one dismissal count everywhere at once, the app, a browser tab, the iCUE panel, a paired phone. Whether you have read the 4.11 announcement is a fact about you, not about which screen you happened to read it on. If you had already dismissed either card, it stays dismissed: the old per-device answer is carried over the first time this build talks to the dashboard engine. If your browser had already wiped it, there is nothing left to carry over, press the button once more and it holds from then on.

  There was a third way to hit this, and it is fixed by the same change: on a screen whose storage is unavailable outright, every one of these writes failed silently. The button worked visually, the card slid away, and nothing was written anywhere. It now takes the settings route, which reports and retries instead of shrugging.

• Ambient now says when a chosen scene is what you are looking at, not your wallpaper

  Someone was told he could put a GIF behind Ambient mode, uploaded one, opened Ambient and saw a painting. Nothing was broken: his Ambient scene was set to an installed one days earlier, and two of the three scene overlays are opaque, they *are* the picture, edge to edge. The setting that was overriding his wallpaper sat three rows above the one he had just used, and the app said nothing either way. That row now carries the note, the same shape as the one the background colour row has carried for the same kind of surprise. A test pins the CSS fact the note asserts, so it cannot quietly become untrue.

• YouTube error 153 no longer marks your whole library unplayable

  Reported on macOS: the account links, every list loads, and no video plays. 153 is the embed refusing the referrer it was opened with, it is not a statement about a video, and it fails on all of them equally. It was being handled like 101/150 ("this video cannot be played inside apps"), which sent the reporter hunting for a video that would work, and each id he tried was added to the remembered set of refusals, so tapping through a library marked the library dead, marks that would have outlived the actual fix. Only 101 and 150 are remembered now; 153 says plainly that it is not the video, and still offers to open it in the browser. The referrer question behind the original report is still open.

• The Media background settings were English-only in six languages

  The whole group, including the sidebar entry for the category, shipped untranslated in Spanish, French, German, Portuguese, Russian and Dutch. Everything around it was translated, so on a Spanish dashboard the one page that uploads a wallpaper was the one page in English, which is exactly how a user, told "Settings → Background", ended up sending a screenshot of that page asking which of the two options it was. An untranslated key is not a blank: it falls back to English and looks deliberate, which is why it survived. A new test walks every language across the whole group so it cannot come undone.

4.11.5 22 August 2026

Added

• You can choose which AI model Xenon uses, and it keeps itself current

  Every provider now has a model list in Settings under Xenon AI, filled from your own account, so it shows what that provider offers today rather than a list written when Xenon was released. Gemini had no picker at all until now, and its four models (chat, advanced reasoning, voice, Live Voice) were fixed in the code.

  Each list starts with "Auto". That is not a model, it is an instruction: use the newest model of that family your key can reach. Pick "Auto" and a model released next month is in use next month, with no update to install. Pick a family, like Flash or Sonnet, and Auto stays inside it, so it never moves you to a more expensive tier on its own. Pick a model by name and it stays that model until you change it. When Auto is selected, the line under the list tells you which model it currently resolves to, so you can always see what is actually running.

  Your existing choices are untouched. If you had picked a ChatGPT or Claude model it stays picked.

• The voice models are selectable too, and the voice no longer depends on one of them surviving

  Gemini's speech and Live Voice models, and OpenAI's transcription and speech models, each have their own entry under "Voice models". Gemini's speech model is a preview model, which is the kind that gets retired, and until now that would have taken the assistant's voice with it. If it ever fails, Xenon now falls back to the local Edge voice that is already installed and needs no key. The voice changes, the feature keeps working.

• A screen mounted vertically gets a layout that fits it

  Until now, turning a display to portrait left the dashboard on its 24 column grid, so the layout you built on a wide screen was drawn as a miniature of itself in a narrow strip. A tall screen now stacks the tiles into one full width column, one under the other, in the same order you read them on the grid. Nothing about your layout is changed or saved over: this is only how it is drawn on that screen, and the dashboard on your other screens is untouched.

  There is a switch for it in Settings under General, called "Tile layout", with Automatic, Single column and Grid. It stays on the device you set it on and is not synced to the others, because the same dashboard is open on screens that want different answers. A tall screen that is still wide enough for the grid, above about 1120 pixels, keeps the grid: turning a screen does not make its columns any narrower, so if the tiles were readable before they are readable after, and only the space under them is new.

• Your supporter code is asked for once, not for every drop

  A supporter code opens every supporter creation, but until now it had to be pasted again for each one, from the email or wherever you had kept it. Xenon now keeps it for you. There is a place for it in Settings, under Widgets and sharing: paste it once and every supporter drop from then on unlocks with a single tap. If you have never been there, the first drop you unlock saves it on its own. Typing a different code still wins, which is what limited and purchased drops need, since those have a code of their own.

  The code stays on that PC. It is never sent back to the dashboard, so it does not travel to a paired phone or to another browser, and the same Settings block says whether this machine holds one and has a button to remove it. If your code is ever replaced, Xenon notices the first time it stops working, forgets it, and asks for the new one instead of failing over and over. Nothing changes about how the code itself works: it is still yours, still good for up to 3 of your devices, still valid while your supporter period is active, and what you have unlocked stays unlocked for good.

• The list of local models to download comes from the website

  Xenon's local AI offered four models chosen when the feature was written. That list now comes from a file on xenon-app.com, so new models can be added without an app update, and it carries the real download size and hardware requirement of each one. Your machine still decides what it can run: the hardware check is local and the built-in limits always win, so nothing on the internet can talk your PC into loading a model it cannot hold. And a model you have already installed is now asked directly what it can do, instead of being guessed at by its name, so a newer model that can read images is no longer treated as text-only.

Fixed

• A Windows install that goes wrong now leaves something to read

  The app you download on Windows is only the screen. The dashboard engine behind it is installed by the Complete setup button on the first-run panel, in a console window that opens for it, and that window was the only place the setup ever said anything. So when it failed, or was closed, or PowerShell hit an error that ended the script and took the window down with its own explanation, nothing was left anywhere on the PC to say what had happened. What you are left looking at is an install folder holding three things, xenon-native.exe, the uninstaller and a windows folder, with no server folder, no Node.js, and no way to tell which step never ran. Reported on Discord more than once, and every time the only way forward was to ask the person to do the whole thing again and watch it happen.

  Every run of the setup is now written to %LOCALAPPDATA%\Xenon\setup.log as it goes, and the run before it is kept beside it as setup.log.1, the interesting one is often the attempt before the retry that finally gets reported. The elevated half of the install, which runs in a second window that closes the instant it ends, appends to that same file, so one file holds the whole story from the download to the last component. INSTALL.bat writes it too. Every run ends by printing where the file is, whether it worked or not, and the first-run panel names it as well when the setup did not take. The uninstaller removes it with everything else.

  And an unexpected error no longer closes the window over its own message. Anything that stops either script the hard way is now caught, named along with the line that raised it, written to the log, and left on screen with the window waiting for you.

• Xenon starts on a laptop running on battery, and no longer stops when you unplug

  The task that starts the dashboard when you sign in was registered with the two conditions Windows applies when nobody says otherwise: do not start on battery, and stop if the charger comes out. On a desktop that never showed. On a laptop it meant the dashboard was missing whenever you were unplugged, and vanished mid-use the moment you pulled the cable, which reads exactly like a crash. New installs no longer carry those conditions. An install you already have keeps them until the app repairs it, which it now offers to do (see the next entry), or you can clear them yourself in Task Scheduler under Xenon Edge Widget, Properties, Conditions.

• Upcoming events show their name instead of their date

  The strip under the calendar gave the date and time all the room they wanted and left the event name whatever was over, which on a row of five events was about thirty pixels: every entry read as a single letter and three dots, and the only way to know what any of them was was to tap it. The name now gets the space. An event today shows its time, and anything later shows how far off it is, like 2d or 3w, which is both shorter and the thing you actually wanted to know from a section called Upcoming. The full date and time are on the tooltip when you hover, and tapping still opens the day.

• Reinstalling now tells you when the startup was the problem

  Running INSTALL.bat again has always re-registered the startup task, which turns it back on, but it did so without a word, so someone whose only problem was a switched-off startup reinstalled, saw it work, and never learned why. The installer now checks first and says it plainly: the startup was off, Xenon does not do that itself, and Windows or a cleanup tool can. It also checks afterwards that the task really did end up switched on, and tells you where the switch is if it did not.

• When Xenon's startup has been switched off, the app says so instead of spinning

  Windows lists Xenon's startup in Task Manager under "Startup apps", and cleanup tools reach the same switch, so it can end up turned off without anything having gone wrong: the dashboard engine is still installed and still works, nothing simply starts it any more. The app could not tell that apart from a missing install, so it waited, then offered to install an engine that was already there, and the setup window answered "already installed, nothing to do". That was a loop with no way out of it. The startup screen now recognises the case, explains it in one line, and offers a button that switches the startup back on and starts Xenon straight away. It also clears the battery conditions above while it is in there, so a laptop that was affected gets both fixed at once. If Windows refuses the change, which happens when it needs an administrator, the screen says that too and tells you where the switch is in Task Manager.

• The app knows the Xeneon Edge is still an Edge when you mount it vertically

  It recognised the panel by its exact size, in landscape only, so a vertical mount reported the two numbers the other way round and stopped matching. The app then opened as an ordinary window filling most of the screen instead of taking the panel full screen, and the "Xeneon Edge" mark disappeared from the screen picker in Settings, which was the one place you could have told it otherwise. It now matches the panel either way up.

• "Advanced reasoning" was quietly not using the advanced model

  The stronger Gemini model it asked for had been retired and was no longer in Google's list, so every request for it failed and fell back to the fast model. Nothing said so, and the setting looked like it was on. Xenon now picks the model from what your key can actually reach, and when a model does disappear it stops asking for it instead of paying a failed request every turn.

• The "Can not find script file … open-dashboard.vbs" box no longer greets you at every sign-in

  Keeping the dashboard open in a real browser registers a small logon task that opens the tab for you, and that task points at a script inside the Xenon folder. The two are set up by different halves of the app and could drift apart: an install that moved left the task carrying the old location, and a script an antivirus had quarantined left it pointing at nothing at all. Windows ran the task either way, found no file, and said so in a box you could only click OK on, once per sign-in, forever, while Xenon itself started perfectly well beside it, which is what made it look like nothing to do with Xenon.

  The task is now checked against what is actually on disk each time the dashboard engine starts: pointed at the right place when the folder has moved, and removed when there is no launcher left for it to run. So the box appears at most once more, at the sign-in after this update, and then stops. Switching the setting on when the script is missing is refused too, with the reason, instead of quietly installing a task that can only fail. If yours was quarantined, Windows Security's Protection history still has it, restoring it and excluding the two Xenon folders (see the README) brings the browser tab back. Reported on Discord.

• The app no longer closes itself without a word, and when something else closes it, there is finally a record of that

  The native shell was built so that a failure anywhere inside it ended the process on the spot: no window, no message, nothing written anywhere, since the app runs with no console to print to. Three of its parts poll Windows for as long as it is open, the watchdog that keeps the dashboard on the screen you chose, and the two guards that look after the mouse and the focus of a running game, and one bad answer from the operating system in any of them was enough to take the whole window down mid-session.

  A failure in one of those watchers is now written down and the watcher started again, with the window left exactly where it was. And whatever happens, the shell keeps a small diary beside its settings: one line when it starts, one when it stops, one when something fails, with the tray menu's Open crash log to open it. That is what separates the two situations that look identical from the outside. A start followed by a failure line is Xenon's own fault, and the line names the exact place it failed, so pasting it into Discord or a bug report is usually all a fix takes. A start with nothing after it means nothing inside the app decided to stop, the process was ended from outside it, which on Windows is nearly always the antivirus quarantining Xenon *while it is running*, hours after it let the installer through. The README now covers that case as well, including the second folder the exclusion has to name: Xenon lives in both %LOCALAPPDATA%\Xenon and %LOCALAPPDATA%\Programs\Xenon, and excluding only the first leaves the half that runs all day exposed. Reported on Discord.

• The calendar is readable on a phone again

  On a phone or a tablet the tiles leave the grid and stack, and each one gets a height worked out from how tall you made it on the desktop. The month grid is six week rows whatever that height turns out to be, so on an ordinary 8 row agenda tile each row was given about 7 pixels for a 13 pixel number: every date was drawn across the two below it, and the whole tile read as damage. A week row now has a floor of 26 pixels, which is also a size a thumb can hit, and the agenda tile has a floor of its own so the month, the tabs and the upcoming events all fit without the tile having to scroll inside itself. The four tabs above it (Calendar, Tasks, Timer, Notes) fit whole down to 360 pixels instead of having the last one cut through, and below that the tabs you are not on shorten with an ellipsis while the one you are on keeps its name.

• The "new in the Store" card no longer paints its own buttons over its list

  When several creations land at once the card lists them, and on a phone screen that list is taller than the card. Nothing was allowed to scroll, so the list took the room and the "Open the Store" button and the opt out below it were squeezed to nothing and drawn on top of the entries, one across a drop's name. The list scrolls now and the two controls stay where they are, and the opt out and "Maybe later" take a second line rather than sharing one that is too narrow for them.

• A limited edition drop can no longer say "undefined of 50 left"

  The number of copies still available is worked out by Xenon's own server before the Store sees it, so anywhere reading the catalogue without it, which is what the browser demo on the website does, had no number to print and printed that. Beside it, a drop whose every copy was already claimed was announced as available, for the same reason. Both numbers are now worked out wherever they are shown, from the copies published and the copies claimed, so a sold out drop reads as sold out and a meter never shows a word where a number belongs.

• The website demo's own badge stays off the app's controls

  Opened on a phone, the green "live demo" pill and the download prompt sat exactly where the dashboard puts its bar of buttons, covering the first of them, and the pill also covered the buttons of any dialog that opened over it. Both now sit above the bar, only one of them appears at a time, and the pill steps aside while a dialog is open.

• Xenon tells you when the file index has run out of room, and which folder it left out

  The index that search and the Disk space widget read has a safety limit on how many files it holds, so it cannot grow without bound on your RAM. Point it at whole drives and that limit is reachable: past it, Xenon stops adding files. The Disk space widget already said so, but Settings under Search, the one place you can do something about it, showed only the file count, which reads as everything having worked. It now says the limit was reached, names the folders that were left out, and tells you that removing one from the list or naming a precise folder instead of a whole drive is the fix. Nothing about the limit itself has changed.

• A file you delete no longer stays in the index forever after that limit is hit

  The index removes entries for files that are gone by re-reading a folder and dropping what it no longer finds. That step was correctly skipped when a read had been cut short, because a partial read is not evidence a file is gone, but the check asked whether the index had *ever* hit its limit rather than whether *this* read was cut short. So the first time any folder reached the limit, removal switched off permanently, for every folder, and deleted files accumulated in the index from then on. Search still refused to open anything that was really gone, so nothing wrong ever happened, but results filled up with names that no longer exist. The check now asks about the read in front of it.

4.11.4 10 August 2026

Added

• The buttons in the top bar are yours to arrange

  Lock, Ambient, Xenon, Search, Layout, Apps and the favourite apps can each be hidden, dragged into the order you want, and moved to the left or the right side. It works the same in the full bar and in the Dynamic Island's side rails, so it does not depend on which of the two you use. Until now the only way to get rid of a button you never press was to close a whole rail, which took the others with it, or to switch the bar off entirely, which did not remove the buttons at all, it just moved them.

  The list is in Settings, under Dynamic Island, below the island elements. Two buttons always stay: Settings and Layout. They are the way back in rather than features, one undoes anything, the other lets you rearrange the dashboard again, and on a touchscreen with no keyboard, hiding either would leave no way to open it. Their eyes are there but greyed out with the reason on them. In exchange they now sit back visually: no plate, no outline, dimmed until you touch them, so the buttons you actually chose to keep are the ones that stand out. The Layout button comes back to full strength while you are editing, since that is a mode worth seeing.

• An empty side rail no longer leaves its arrow behind

  In the Dynamic Island's minimal chrome, moving every button to one side left the other rail as a lone arrow that opened an empty capsule. A rail with nothing in it now goes away entirely, and comes back the moment something lands in it, a button moved over, an app you star, or a widget drawing into the mini slot. It can never take both rails with it, since Settings and Layout cannot be hidden.

• The clock is centred again when you strip the bar down

  With the date, the weather and the music hidden, the row under the time still held the small connection dot, and the clock is centred as a block, so the time sat 5.5px above the middle of the bar and read as crooked. The dot keeps its place under the digits, but it no longer pushes them up.

• The space you free can hold something

  A widget can now draw a small readout among the buttons, a temperature, a count, a meter, with one button you can press, in the position you put it. It is drawn by Xenon rather than by the widget, like the island and the badges, so nothing about how widgets are sandboxed changes. You choose which side it sits on, you can hide it, and you can switch any single widget's contribution off on its own.

• Everything a widget puts in the bar is listed in one place, with a switch each

  Whether it writes a line in the island, a chip next to the clock or a mini widget among the buttons, the extension shows up in Settings under Dynamic Island with what it adds and a switch to turn it off, without uninstalling it. That list existed but only ever said "island", so a widget sitting somewhere else in the bar was hard to connect to it.

• One button puts the whole bar back

  It resets the style, the island elements, the button layout, the side rails, the clock format, and switches every extension back on. It now asks first: it undoes an arrangement you may have spent time on, and there is no way back from it.

• Badges next to the clock can be tapped

  They were display-only. A widget can now ask for its badge to be a button, and it is a permission you grant separately from the badge itself, so a widget that could only show you a number cannot quietly become one you can press after an update.

• Your dashboard pages can have names, and the dots at the top can show them

  Until now the pages were a row of identical dots: nothing told you which one held your music and which one held your PC stats, and you found out by swiping. In Layout mode there is now a pencil button next to the page controls that names the page you are on, and a switch in Settings under Dynamic Island, on the "Page dots" row, turns those dots into buttons carrying the names. It works in the normal top bar and in the island, so it does not depend on which of the two you use.

  The switch is off to begin with, so nothing changes for a dashboard you have already arranged. A long name is shortened to fit rather than pushing the bar wider, and clearing the name field puts the page back to the name it started with instead of leaving it blank.

Fixed

• The weather tile no longer empties for good until you reload the dashboard

  After a while it went blank and stayed blank, however long you left it, while the weather itself was perfectly available, opening the same address in a browser at that exact moment returned the forecast. Only reloading the page by hand brought it back, and then it happened again.

  The cause is that a request to fetch the weather had no time limit. Almost always it answers in a moment, but if one ever hangs, a sleep and resume, a hiccup in the network stack, it never finishes and never fails either. Xenon skips a refresh while the previous one is still going, so a request that never ends means every later refresh is skipped too, for as long as the page stays open. On a dashboard left running for days, it only has to happen once. Requests now have a deadline, so a stuck one is abandoned and the next refresh goes ahead normally.

  The same gap existed in the readings for system, network and audio, and is closed there too. And when a refresh does fail, the tile now keeps the last forecast and marks it as not current, instead of throwing it away: one from a few minutes ago is still worth reading. Past three hours old it stops pretending and tells you what went wrong. Reported on Discord.

• The weather no longer depends on one single service being reachable

  To ask for a forecast Xenon first has to know where you are, and in automatic mode it got that from one address on the internet. If your PC could not reach that one address, and a DNS blocker, a router filter, an antivirus web filter or a company network is enough to do it, then nothing said so: the two good forecast services need coordinates and were skipped without a word, and the whole feature quietly fell back to the third and least reliable one. It kept working, with the coarser data and the odd "next hours" line that came with it, until the day that last service was busy too and the tile went blank.

  Xenon now asks a second and a third source when the first does not answer, so one blocked address is no longer enough to take the weather down. Nothing changes when the first one works: it is asked, it answers, and the others are never contacted.

• A weather tile that cannot show anything now says why

  It used to say "Weather unavailable" and stop there, which is the same sentence for three completely different problems: your position could not be determined, the city you typed does not exist, or the weather services did not answer. Only one of them is fixable by you, and there was no way to tell which one you had. The tile now names the cause, and the details panel adds a line on what to do about it: check the connection or a blocker, try a nearby city name, or simply wait for the next refresh. In all eleven languages.

• The YouTube and Twitch widgets now tell you they need an account, instead of sitting there empty

  With no account connected, both tiles took all their contents off screen and left the logo on an empty background. Nothing said why, nothing offered a way forward, and the tile looked identical to one that had broken. It was most confusing in layout editing mode, which forces the contents back into view: the widget appeared to work there and appeared broken everywhere else, which reads like a display fault rather than a setting.

  Each tile now shows one line saying the account has to be connected, and tapping it opens the page where you connect it. This covers the YouTube watching widget, the YouTube Live widget and the Twitch watching widget. The YouTube Live tile had that line already, but it lived inside the panel that gets hidden, so it disappeared at exactly the moment it was the only thing worth saying.

• Those widgets no longer say "Loading…" over an answer they already have

  The video and channel lists showed the loading line for two different situations: the check for a connected account still being in flight, and that check having come back with a definite no. The second one never resolves, so the list sat on "Loading…" indefinitely on a dashboard where nothing was actually loading. A definite no now says the account is not connected.

• Five languages showed one of those messages in English

  Spanish, French, German, Portuguese and Russian had no translation for the "connect in Settings" line used by the Discord widget, so it fell back to English while the identical line in the YouTube widget right next to it was translated. All the new text here is available in all 11 languages.

• Xenon no longer opens in the shape of a screen you may not own

  On a PC with no CORSAIR Xeneon Edge attached, the app opened as a window with that 14.5" panel's own 3.556:1 proportions, up to 1600×450, whatever monitor you actually have. On an ordinary screen that is a wide slot across the middle with desktop showing above and below it, and it was the first thing you saw after installing. The window now opens at the size of the screen hosting it: that monitor's own proportions, at 88% of it, centred. Where an Edge *is* attached nothing changes, that panel is still taken over whole, which is the point of it.

  Two quieter versions of the same mistake went with it. The window was built at 2560×720 before anything resized it, which is the Edge's exact resolution, and on macOS, where it cannot be created full-screen, that first frame was what you got. And it was created full-screen on every machine and then immediately shrunk, so opening Xenon covered your entire desktop for a moment and then did not. It is now built at the size it is going to keep, and full-screen only where a real Edge is waiting for it.

• The first question Xenon asks now has your screens in it

  On first run it asks whether the dashboard should live on this PC or on your phone or tablet, and the "on this PC" side is meant to list your monitors so you can say which one. That list only arrived with the first update the app sends the page after the dashboard has finished loading, so the question could open with no screens on it, and if that update never landed, it stayed that way: a question about which screen to use, asked without offering one. The screens are now handed to the page before it loads, so they are there from the first frame, and they still redraw the moment a monitor is plugged in or out.

  And a screen can now be picked whatever your system calls it, which, on two of the three platforms, was not a given. On Linux an output the system has no model string for had no identity to save, so the tray menu left it out of "Show on" altogether and the picker drew it as a button that refused to be pressed: the screen was listed and could not be chosen, and on a machine where nothing is named the question had no answer at all. On macOS the opposite problem: every screen is named, but the name is the display's model number, so two identical monitors, the ordinary way to own two, were the same screen as far as Xenon was concerned. Both showed as the primary one, the tray offered two entries that did the same thing, and choosing the second one moved the window to the first, quietly and for good. A screen is now identified by where it is when its name cannot tell it apart from another.

  One limit worth knowing on Linux: under Wayland a window is not allowed to place itself, so which screen it opens on is the compositor's decision, not Xenon's. The choice is saved either way, and it is honoured on Windows, on macOS and on X11.

4.11.3 6 August 2026

Added

• macOS stops forgetting Xenon's permissions every time it updates

  This is the cause of most of what is fixed below, and it had been true since the Mac build shipped. macOS ties a permission, Full Disk Access above all, to the app's code signature, and Xenon's signature was generated fresh at every build. So every release looked to macOS like a completely different app, and everything you had allowed silently stopped applying: the switch in System Settings still showed as on, and did nothing, because that list shows a name while macOS compares a signature.

  Xenon now carries its own certificate, which stays the same from one release to the next, so a permission granted once keeps working. The update to this version resets it one final time, since this is the release where the identity changes: grant it again here and you should not have to think about it after that. Two honest notes. This does not remove the warning macOS shows the first time you open Xenon, that needs Apple's paid notarization, which this project still does not have. And the certificate is Xenon's own rather than Apple-issued, which is exactly why it is free and why it is enough for this particular problem.

Fixed

• No more storm of permission requests on a Mac

  When the permission above had lapsed, Xenon's file index kept trying to read your home folder anyway, so macOS asked for the Desktop, then Documents, then Downloads, then Photos, then Music, and asked again on the next pass, and the next. It made the machine genuinely hard to use, and nothing on screen connected it to Xenon having lost a permission after an update.

  Xenon now checks whether the permission is really in force, and while it is not it simply stays out of your home folder rather than knocking on every protected door in it. Instead you get one notice that says what happened, with a button that opens the right settings pane, it is buried four levels deep and named differently on each macOS version, so pointing at it beats describing it. A folder you picked yourself is still indexed: you chose that one. And when you grant the permission, search and the disk map come back on their own within a minute, with nothing to restart.

• Buttons on notifications did nothing

  Any notification offering a choice, the one above, and the update notice's "Skip this version", swallowed the tap: the card's swipe-to-dismiss gesture captured it before the button saw it. Worse on the update notice, where the tap fell through to the card's own action, so declining a version installed it instead.

• The first install on a Mac now ends with the dashboard on screen, instead of a spinner and an error

  With 4.11.2 the setup finally ran to the end, it downloaded Xenon, installed it, registered it to start at login, and then nothing started it. The window reported that the dashboard had not answered, and the app kept turning on "Waiting for the Xenon service" forever, on an installation that had actually succeeded. Quitting Xenon and opening it again fixed it, which is not something anyone should have to guess.

  The reason is that the piece which starts the dashboard is Xenon itself, and Xenon was already open, it is what opened the setup window in the first place. It looks for a dashboard once, when it launches, and at that moment there was nothing installed yet to find. The command that starts Xenon at login does nothing when Xenon is already running, so no one ever asked it to look again. The installer now closes and reopens the app itself once the install is done, so that second look happens. Xenon holds the dashboard on a Mac on purpose: started that way it inherits the app's Full Disk Access, which is what lets the Disk widget and search see the Trash and your caches.

4.11.2 6 August 2026

Fixed

• Installing Xenon on a Mac from the .dmg now finishes

  The app opened, the setup window appeared, it found the release, downloaded it and verified its signature, and then stopped on the line right before it started copying anything, with INSTALL_ROOT: unbound variable. The window closed itself, nothing was installed, and the app sat on "Waiting for the Xenon service..." forever. There was no way to tell from the outside that anything had gone wrong.

  The cause was one missing pair of braces. macOS still ships bash 3.2, released in 2007, and that version reads the bytes of the … character glued to the end of a variable name as part of the name, so a message meant to say "Installing to <folder>…" asked for a variable that does not exist, and the script is set to stop dead rather than continue on an empty path. Every other shell, including the one on Linux and the one your Terminal opens by default, handles it correctly, which is why it only ever happened on a Mac.

• Uninstalling on a Mac now works too, in v4.11.1 it stopped before removing anything

  The same line was in the uninstaller, at the point where it stops the running dashboard, so on a Mac it quit right there: no app removed, no login item removed, nothing. If you ran it and Xenon was still on your machine afterwards, that is why, run it again from this version and it will finish the job. A test now refuses to let that shape of line back into any script in the project, and every shipped script was checked against the shell macOS actually runs them with.

4.11.1 6 August 2026

Fixed

• Uninstalling on macOS and Linux now actually uninstalls Xenon

  It stopped the backend and removed the startup entry, and then printed a list of the things it had deliberately left behind: the app, the folder, your data. That list made sense to whoever wrote it and to nobody else. What you saw was an uninstaller that finished, a Xenon icon still sitting in Applications, and Xenon still coming up when you searched for it, so the reasonable conclusion was that it had not worked. Worse, opening that leftover app re-registered its own start-at-login entry, so a machine you thought was clean started Xenon again at the next sign-in.

  It now removes Xenon: the app itself, wherever it is. On macOS every copy of Xenon.app is found by its identity rather than by its name, unregistered from the system's app database first, that database is what Spotlight, Launchpad and "Open with" actually read, and it keeps its entry for an app that was only deleted, which is why a Xenon dragged to the Trash could still be found and opened. On Linux the .deb/.rpm package, any AppImage in the folders people keep them in, and the launcher entries that put the icon in the app menu. Then the login items, the local server, the browser windows Xenon had opened, your data and the install folder itself, matching what UNINSTALL.bat has done on Windows since v4.4.0.

  Because it now deletes rather than keeps, it asks first: it lists exactly what is about to go and waits for you to type REMOVE. --keep-data keeps your settings, layouts and notes (and the folder they live in), --keep-files keeps just the folder, --dry-run shows you the whole list and changes nothing, and --yes skips the question in a script. --purge-data still works and is now simply what happens anyway. All three uninstallers also leave a folder alone when it is a git checkout rather than an install, that is somebody's working copy, with branches and unpushed commits in it.

  And on macOS the Terminal window closes itself when it is done. Terminal leaves a finished window on screen saying "[Process completed]", which after an uninstall reads as if something is still running, and left the very last thing on your screen being a window belonging to the app you had just removed.

• The macOS installer window now shows you what to do with it

  Opening the .dmg gave you a plain window with the Xenon app sitting to the *right* of the Applications folder, so the drag everyone knows read backwards, at whatever size and spacing Finder felt like, and anyone who has hidden files visible also got the volume's icon file in there. The window had no layout at all because the tool that builds the image skips that step, by a flag whose own description says it produces "a DMG without any custom background or icons positioning". The layout is now decided once and carried inside the image itself, rather than asking the build machine to arrange it in Finder, which needs a desktop session no build server has, and which fails the whole build when it goes wrong. App on the left, Applications on the right, drag from one to the other.

• Opening Xenon for the first time on a Mac could install nothing at all, in silence

  A .dmg cannot run an installer, so the first launch opens a Terminal window that sets the backend up. macOS has no way to hand a command to Terminal: it starts a window, starts a shell in it, and *types* the command at that shell, and if the shell is still starting, what arrives is garbled. Seen in the wild as command not found: o. The window opened, did nothing, and Xenon sat on "Waiting for the Xenon service…" forever, with nothing anywhere to say why. The app now waits for the setup to confirm it really started and opens the window once more if it did not.

• The YouTube widget now tells you when a video will not play, instead of leaving YouTube's own error on screen

  Some videos cannot be played outside YouTube itself. That is a decision of whoever owns the video or the music inside it, not of Xenon, which is why videos from a channel you follow can work while others from that same channel do not, and why all of them still play fine on YouTube. Xenon already knew about this case and offered to open the video in your browser, but the offer was a line of text below the controls, while YouTube's own "Video unavailable" rectangle stayed sitting over the whole picture. So the only thing you actually saw was the error, and it looked like the widget was broken. Now the explanation and the Open in the browser button are drawn over the picture, in place of that rectangle.

  There was also a case where nothing was said at all: when YouTube refuses a video, what it puts in the frame is a plain error page, and that page cannot talk to Xenon. If that happened, the widget waited for a player that was never coming and left the black box there. It now gives that wait a deadline and shows the same explanation.

  And the list now says which videos those are, before you tap them. Finding out one tap at a time is tiring, and a playlist of live sets or DJ mixes can be mostly made of them. YouTube says so up front, in the same request that already fetches how long each video is, so it costs nothing extra: those videos carry a small YouTube only tag in the list, and tapping one takes you straight to your browser instead of starting a player that was going to refuse.

  Playing a whole list works again as well. Tapping a video plays everything after it, and one video that will not play used to stop the lot. Marked videos are left out of that queue, so a playlist plays the ones it can.

• The YouTube widget was still in English for five languages

  Spanish, French, German, Portuguese and Russian never had translations, so anyone using Xenon in one of them got the whole widget in English: the tabs, the player controls, the live broadcasting panel and every message it can show. All of it is translated now.