vikix.GuideInstallSource

23 The commands

Every vikix command: its forms, what each does, and the files it keeps. This page is made from the header each command’s script starts with (lib/man.py --guide): the lines its -h prints, and the ones its man page is made from (man vikix-backup), so the three always say the same. Nobody edits it by hand.

vikix is the one you type, and most of the others are reached through it: vikix backup runs vikix-backup. A few are what the desktop itself runs: the bar’s fields, the session, the lock.


23.1 vikix

The everyday command.

Each command has a man page with the whole of it: man vikix-NAME (man vikix is this list; man -k vikix lists the pages).

vk is the same command, shorter. A command can be given by the start of its name when only one begins so (vk upd), and so can the word after it (vk docs f runit); a command’s start that fits several says which, unless the shortest of them starts all the others (vk vers is version, not versions). Tab completes them.


23.2 vikix-agent

An AI agent in this terminal, after a snapshot of your files.

An AI agent in this terminal, after a snapshot of your files (so whatever it changes can be seen with vikix changes, and undone with vikix undo). Super+a and vikix agent (alias: a) start it.

Every agent is told how Vikix works by the same guide: Claude Code and OpenCode read the Vikix skill (~/.claude/skills/vikix); the others read ~/.local/share/vikix/AGENTS.md, made from that skill at each update and each start: linked as ~/.codex/AGENTS.md, imported by a one-line ~/.gemini/GEMINI.md, included by a rule file of Vikix’s own for Antigravity CLI (~/.gemini/antigravity-cli/rules/vikix.md), given to Aider with –read; never over a file of yours.

Antigravity CLI (agy) is where a personal Google account signs in now: in June 2026 Gemini CLI stopped serving the free, AI Pro and AI Ultra accounts, and keeps working with a Gemini API key or a Code Assist licence from work. Both are here. Antigravity signs in in your browser at its first start and keeps the sign-in in the system keyring (/logout in it drops it); with modelProvider gemini in its settings it uses GEMINI_API_KEY instead, which it then keeps from vikix ai key.

What an agent doesn’t get, so a prompt injection (a web page, a README it reads) can’t use it: your API keys and other secrets from the environment (each agent signs in its own way; Aider has no login, so it keeps the model companies’ keys; VIKIX_AGENT_API_KEY=1 keeps them all), and your SSH agent, which after your first push would let it push as you (VIKIX_AGENT_SSH=1 keeps it). This prevents accidents; it isn’t a sandbox: the agent runs as you and can read your files.

Nor the marks a running agent leaves on its children (CHILD_MARKS below): an agent started from inside a Claude Code session (its Bash tool, the MCP server’s office tool opening a desk) would take itself for a child of that session, and Claude Code then saves no transcript of it ("Transcript saving is off: inherited CLAUDE_CODE_CHILD_SESSION marker"; vikix agents resume finds nothing). A desk’s agent is a session of its own.

Claude Code and Antigravity CLI also get the office’s house rules: a hook that runs vikix agents touch before each edit, so two agents on one file are caught and a crossing into another agent’s folder is recorded (see vikix agents). Claude Code gets it for the session; agy takes no such option, so for it the hook is a plugin of Vikix’s (agy plugin list shows vikix), put in place at each start. VIKIX_OFFICE=0 leaves it out, and for agy leaves the plugin as it is.

Claude Code asks "do you trust the files in this folder?" once a folder, and keeps the answer in ~/.claude.json (projects[FOLDER]. hasTrustDialogAccepted). Inside a repository it looks no further up than the repository’s root, and a desk, a git worktree, is a root of its own: so every new desk asked again, however long ~/src/vikix had been trusted. At a desk whose project’s own folder you trusted, the start writes the same answer for the desk into that file first (the key Claude Code’s own message names; nothing else of the file is touched; Vid’s decision, 2026-10-22), so the question isn’t asked. A desk of a repository you never trusted still asks. VIKIX_CLAUDE_TRUST=ask keeps the question everywhere. Your home can’t be trusted this way: Claude Code keeps the home’s answer for the session only ("home trust is session-only"), so Super+a’s agent here asks at each start, and the start says so.

Codex gets three more things on its command line, for the session only (~/.codex/config.toml is yours and is never written). The repository’s instructions: Codex reads AGENTS.md from the repository’s root down to the folder, never CLAUDE.md, so a repository with only a CLAUDE.md (Vikix, most projects made with Claude Code) is given it as the file to fall back on, with Codex’s cap raised to hold it whole; a repository with an AGENTS.md is read as its author meant. A mode (–mode above): at a desk (a git worktree) and in a folder of no repository (your home, where Super+a’s "agent here" starts) the house default, mode= in ~/.config/vikix/office, which Vikix writes as autonomous the first time; in a repository that isn’t a desk (a project’s own folder, a stranger’s) Codex runs as your own settings say unless –mode is typed. (Until 0.72.50 the home session ran on ~/.codex/config.toml alone, and a header out of place there, [section], had Codex read-only and asking for every write: vikix doctor and vikix agents hooks codex now say so.) The two sandboxed modes make this folder Codex’s only writable root (your writable_roots are set aside for the session), so from a desk the project’s own folder, ~/vikix and the other desks are read-only to what Codex runs, and link Vikix’s rules (~/.codex/rules/vikix.rules, through vikix agents hooks codex –install) which let a desk’s day (git on its branch, the tests, vikix, the release) out of the sandbox without a prompt once Codex asks to (inside it a desk’s .git and ~/.local/state are read-only, so a commit or a handoff fails there; the worker’s first prompt says so); Codex’s own matching stops at the first word (timeout 20s vikix snapshot ... asked each time), so the house rules’ hook on each step out of the sandbox (PermissionRequest) allows the same commands whatever wraps them. And trust for that hook: Codex runs a hook of yours only once you trusted it in /hooks, by its hash, which every release that changes the file undoes; when ~/.codex/hooks.json is Vikix’s and the folder is one of your projects (vikix project list) or no repository at all, the start passes –dangerously-bypass-hook-trust, since Vikix vets that file by making it; in a stranger’s repository Codex’s own prompt stays. VIKIX_CODEX_HOOK_TRUST=ask keeps the prompt everywhere.


23.3 vikix-agents

The agents at work on this desktop, in one place.

Several agents run side by side, each in a terminal of its own, and five windows called "Alacritty" don’t say which is which. The desktop starts them (vikix agent, Super+a), so it knows: it finds the agent in each terminal, started by vikix agent or by hand at a shell, and reads what it is doing from the agent-waiting plugin’s note for its window (when you have that plugin: vikix plugin add agent-waiting) and from the mark Claude Code keeps at the front of its window’s title. Nothing is asked of the agents themselves.

An agent an editor started (vikix agent –acp: Emacs’s agent-shell, Neovim’s CodeCompanion) has no window of its own; it is listed last, with what started it.

Super+m, AI, "Agents: who is running" is the same list on the desktop: pick one to go to its window.

A desk: Super+a starts an agent in your home folder, and what it works on is whatever you tell it; two of them on one project then edit the same files. vikix agents desk gives each its own copy to work in. The worktree is an ordinary git one: the agent commits on its branch there, and when its work is in (merged, as the project’s own notes say), the desk goes with git worktree remove FOLDER and git branch -d TOPIC in the project; vikix agents close does both once the agent there has finished, and keeps a branch that isn’t merged yet. A desk that is still there is used again, not made twice. A project that isn’t a git repository has no worktrees: its agent works in the folder itself. Super+m, AI, "Agents: start one on a project" and "Agents: close a desk" are the same, asking which.

An agent’s terminal is named for its desk on the desktop: "wifi-fix · Claude", the topic and the provider, in the title bar, the window list, the overview and the palette, from the moment the agent is at the desk (started there, seated with sit, or resumed) until it leaves. Two of one provider at a desk are "wifi-fix · Claude 1" and "wifi-fix · Claude 2", each keeping its number while it runs. The title the agent itself writes (Claude Code’s turning mark) is kept apart, and still says what it is doing; a terminal with no agent is left as it is. The listing and the Office show the same name (desk_title in –json). An agent off any desk is named for its folder the same way ("~ · Claude" in the home folder, "notes · Codex" in ~/src/notes), so two are told apart.

No desk, no work on a repository: an agent edits the files of a project’s repository (any of vikix project’s that is one) only from a desk, a worktree of its own, and never in the project’s own folder, which is for merging only. Claude Code’s hook refuses the edit otherwise and tells the agent how to take a desk from where it sits: vikix agents sit PROJECT TOPIC seats it at the worktree PROJECT-TOPIC without a restart (the seats: ~/.local/state/vikix/office/seats.jsonl, kept while the agent runs). An agent started by vikix agents desk is at one already. A Bash command that would write into a repository (sed -i, a redirection, mv, git commit and the like) is held to the same rule; one that only reads is not. A repository that is no project (~/.dotfiles) is not ruled.

A handoff: each desk keeps a small record across agent exits and reboots (~/.local/state/vikix/office/desks/ID.json, lib/handoff.py; the id is the repository’s and the worktree’s, never a process’s): the user’s task in their words, what the agent says of its work (status, an estimate of how long barring a major issue, account, next), what Vikix read itself (commit, branch, uncommitted files at each write; for a check, the commit it ran on and whether the tree was dirty) and the providers’ resumable session ids. The three stay apart, each line says who wrote it, no transcript is copied and no credential is kept. Agents of every kind use the same commands (and the MCP tools handoff and handoff_update): read the handoff when joining a desk, say how long when starting, set it when handing work back, blocked, or done. vikix agents close marks the record closed and keeps it.

A desk is a place: the worktree, its branch, its record; a worker is an agent at a desk with a task. vikix agents desk makes the place, vikix agents worker starts an agent on a task there, the task its first prompt, and a desk takes its workers one after another on the same branch, the record keeping each one’s task and how it ended (desk –task does both in one go). A worker reports by construction: an agent’s status coming to review, waiting or finished is a notification on the desktop, and a worker that changed files in a turn without writing its handoff is asked once to, by Claude Code’s Stop hook, before it stops. A note for a worker at work (vikix agents tell) reaches it at its next edit or command, through the same hook that holds the house rules, and never by typing into its window. The same hook holds a paused worker (vikix agents pause) at its next call, a second entry of it before every tool, Read too, so a pause takes hold at the next thing it does; and with turns on (vikix agents turns) it waits at a clash for the other agent’s commit rather than asking you. A hand-in (status review) runs the desk’s tests (vikix agents test): a script, never an agent, whose result lands in the record and the worker’s inbox; not again after a run of tests/run.sh that passed at the desk on that very commit (a run at a desk records itself), nor beside one still going.

The house rules: the office keeps a journal of what each agent edits (~/.local/state/vikix/office/journal.jsonl, pruned to the agents still running), fed by the hook vikix agent gives Claude Code (vikix agents touch). From it and from git it knows when two agents are on one file: the one that comes second is stopped at Claude Code’s own question to you, with the other agent’s name, and vikix agents clash FILE shows both changes for you to choose; vikix agents marks the file under both agents. An agent may edit a file in another agent’s folder, or go to another agent’s window (the MCP tool focus_window), but never quietly: the crossing is told to it and recorded (vikix records, plugin office, kind crossing), and vikix agents crossings lists them. Antigravity CLI (agy) runs the same hook, as a plugin of Vikix’s that vikix agent puts in place (agy plugin list shows vikix); its hooks can’t tell the agent something without deciding, so there a crossing asks you, with the reason. Codex runs it from ~/.codex/hooks.json (vikix agents hooks codex –install; vikix agent trusts the file for you in your projects): its apply_patch is read for every file it names, a clash is refused once since its hook can’t ask, a step out of its sandbox that would write off the desk is denied and a routine one (vikix snapshot, a commit, the tests, wrapped or not) allowed (PermissionRequest), and a turn begun and a stop let through are noted, so the listing says working and at its prompt for it as it does for Claude Code. OpenCode’s plugin holds the edit hook alone. Gemini CLI and Aider have none: for them the rules hold through git alone, so a clash with one of them is seen in the listing, not before the edit.


23.4 vikix-ai

AI services on Vikix: keys, and local models.

The keys are kept in ~/.config/vikix/secrets/, only yours to read, and every new shell and the desktop session have them as variables (ANTHROPIC_API_KEY ...). They’re never in the snapshot history of your files: a key in ~/.bashrc would be kept there for ever.


23.5 vikix-ask

AI on the text you selected, anywhere on the desktop (Super+i).

The text is what you last highlighted (X keeps it after the highlight is gone), else the clipboard: the notification while it works shows it. Proofread, Rewrite and Translate put their result on the clipboard, to paste where you want it; Ask and Explain show the answer, in a notification when it’s short, else in a terminal. A local model and Claude answer through llm (vikix ai llm), so it’s all kept: vikix ai log shows the last questions and answers (Codex’s aren’t, it answers without llm).

Which model answers is yours to choose, in ~/.config/vikix/ai (made on first use): a local one (free, offline, the text stays on this laptop), Claude (better, paid, the text goes to Anthropic), Codex (the Codex you installed and signed in to with codex login; the text goes to OpenAI), or a cloud service that speaks OpenAI’s API (use=cloud: OpenRouter unless cloud_url= says another, with a key of yours by name, cloud_key=, and the service’s model in cloud_model=; the text goes to that service and the model’s host; lib/cloud-ask.sh). It never leaves the local model by itself.

Codex is an agent, so Super+i asks it with its tools switched off: no commands, no web search, none of the apps connected to your ChatGPT account, and nothing kept of the session. What you select can come from any page, and a line in it written for an agent finds nothing to act with. It takes some ten seconds an answer, fewer with a faster model (model=) and effort=low in that file, which leave Codex in the terminal as it was; the editors’ chats and note know only local and Claude, and stay on the local model meanwhile.


23.6 vikix-back

Where you were, when you come back to the laptop.

Everything is read from what is kept anyway: the desktop’s screen log (vikix day: the workspace, project, program and folder that had the screen, and when nobody was at the keyboard), the project’s log and its git history (vikix project), Emacs (asked over its socket, for two seconds at most), your shell history (atuin’s, for the project’s folder, when you use atuin; else the end of ~/.bash_history) and the inbox’s file (the inbox plugin). Nothing is written.

The card comes when the desktop sees you back (day.lisp, every 30 seconds), so not when the screen log is off ((setf *vikix-day-on* nil)). Another wait: (setf *vikix-back-after* 1800) in ~/.stumpwm.d/user.lisp, in seconds; nil, never.


23.7 vikix-backup

Your home folder, backed up with restic.

Every backup is encrypted with the password in ~/.config/vikix/backup-password, made at setup and readable only by you. Keep a copy somewhere else: without it, a lost laptop means backups nobody can read. Old backups thin out after each run: one a day for a week, one a week for a month, one a month for a year. The bar says "backup 9d" once the last backup is older than DAYS (7) in ~/.config/vikix/backup; nothing runs by itself. A click on that note is a menu: back up now, status, the card, check; or set up.


23.8 vikix-battery

Warn on low battery and suspend before it runs out.

vikix-session starts it on machines that have a battery. Once a minute it reads the first battery’s charge, every 15 seconds at 15% or below. While discharging it warns at 15%, then urgently at 5% and suspends if no power supply is online. xss-lock locks before sleep in a Vikix session. After a successful request it waits two minutes before checking again, giving you time after waking to plug in. A failed request retries after one minute. Plugging in resets both warnings.

VIKIX_BATTERY_LOW and VIKIX_BATTERY_CRITICAL change the two levels. Critical sleep also applies while keep-awake is on or idle sleep is off. Sleep still uses power: plug in before the remaining charge runs out.


23.9 vikix-bitwarden

Your Bitwarden vault on the desktop.

Your Bitwarden vault on the desktop: Super+Alt+v opens a picker of your logins, and Enter types the password into the window you were in. rbw reads the vault (an agent keeps it unlocked for an hour, as ssh-agent does); rofi-rbw is the picker; your master password is only ever typed into pinentry’s box, never seen by Vikix.

In the picker (rofi-rbw’s keys): Enter types the username, Tab, then the password, for a sign-in form; Alt+3 types the password alone (a password box), Alt+2 the username, Alt+4 the two-factor code (a Premium account’s); Alt+c copies the password, Alt+u the username, Alt+t the code (gone from the clipboard after 45 seconds); Alt+m shows every field of the login; Alt+s syncs. Its settings are yours: ~/.config/rofi-rbw.rc.


23.10 vikix-bt

Bluetooth as one short line, for the mode line.

bt                  on, nothing connected
bt WH-1000XM4 80%   a device connected: its name, and its battery if it says
bt Buds +1          and another one besides

Prints nothing when there is no Bluetooth, when it’s switched off, or when bluetoothd isn’t answering, so the bar leaves the field out. Asks bluez through bluetoothctl, each question with a time limit: a hung bluetoothd must not hold up the bar.


23.11 vikix-cuis

Cuis Smalltalk as a Vikix program.

Cuis Smalltalk as a Vikix program: a live image, pinned, built from packages, with a door for vikix eval and the agents.

The door: vikix eval –cuis ’3 + 4’ prints 7. The image evaluates what it is sent in its own UI process, after the first line of ~/.slime-secret, as Swank in StumpWM does (port 4004) and Nyxt (4006). An agent’s expression is walked first (VikixWalker, in the image): every global it names and every message it sends must be on the walker’s lists, or it is held in the image for you (VikixServer held in a Workspace, then VikixServer runHeld: N or dropHeld: N), with a notification; your own names for the lists go in ~/.config/vikix/door, the Lisp door’s file. The theme: vikix theme writes the Vikix theme as a class, ~/.config/vikix/theme/cuis.st (VikixTheme’s colours and the font), and files it into the running image through the door; cuis reads it as it starts. Cuis’s own files (UserChanges, Logs, NewPackages, your preferences) are in ~/cuis: the image is started with -ud there, so nothing lands in the folder you started it from.


23.12 vikix-day

The day as the desktop saw it, kept as a diary.

Nothing is asked of you during the day. Everything here is read from records Vikix keeps anyway: the projects’ logs and commits (vikix project), Esploro’s journal of changes, the snapshot history of your settings (vikix history), the record store (vikix records), and one of its own: ~/.local/state/vikix/day/screen-YYYY-MM.log, where the desktop notes every 30 seconds which workspace, project, program and folder had the screen when that changed (day.lisp; never a window’s title). Five minutes without a key or the pointer is time away, and so is a suspend. A window counts for a project when its workspace was opened for it (vikix project open) or its program is in the project’s folder, or in a git worktree of it. A commit counts for the project whose folder holds a file it changed, so a repo of many projects (a collection) gives each its own.

The file is yours and private: ~/journal is made 700 and each day 600, it is in vikix backup like the rest of your home, and nothing sends it anywhere. Each run writes the day again from the records, so yesterday can be asked for tomorrow; what you write under its last heading, Notes, is kept. Another folder: a line folder=~/Notes/journal in ~/.config/vikix/day. To record nothing about the screen: (setf *vikix-day-on* nil) in ~/.stumpwm.d/user.lisp; the rest still works.

An agent asked "what did I do on Tuesday" runs vikix day DATE –no-file, or reads the day’s file.


23.13 vikix-debug

One file that says what’s going on, to attach to an issue or hand to an agent.

In it: the problems at a glance, Vikix’s version and checkout, what changed lately, the system, the hardware and screens, your features, what vikix doctor says, the services, and Vikix’s own lines from the logs (the session’s start and end, the last install and update), the desktop’s latest errors (~/.local/state/vikix/errors/), X’s errors. Left out: other programs’ log lines (a browser’s carry the pages you had open, and text a web page chose), web addresses’ paths, and (by lib/debug-report.py) your secrets, whatever their shape, your home path, user, full and machine names. The finished file is checked once more.


23.14 vikix-dictate

Speak, and it types what you said.

Speak, and it types what you said. On this laptop only: whisper.cpp, built from source, turns your voice into text on the CPU.

While it listens, the bar says mic. On stop, the text is typed into the window you were in when you pressed the key, once it’s written down (and put on the clipboard, in case that window didn’t take it; if you’ve moved to another window meanwhile, it’s only put on the clipboard). The recording is kept only until it’s written down, in your runtime folder (memory, yours alone); nothing leaves the laptop.


23.15 vikix-docs

Every document on the machine in one catalogue, found from one key.

What it covers, each with whose words they are: Vikix’s guides (vikix); the README, DESIGN, TODO, CLAUDE and log files, plans/ and docs/ of your projects in ~/src (repo); the language guides in ~/dev (dev); your Org notes in ~/Dropbox/notes (note); your own documents, the folders you name (own, below); the classes of the Cuis Smalltalk image (cuis: a row a package and a row a class, its comment and its method categories, read from the package files, Vikix’s in the checkout, yours in ~/cuis/NewPackages and Cuis’s own in ~/cuis/Packages, when Cuis is installed); every man page (man) and Info manual (info) on the machine; the tldr pages (tldr: a command’s worked examples, where a man page has its options) and the ArchWiki (arch), the English pages of each as wikiman keeps them in /usr/share/doc, when they’re there; the READMEs, notes and PDFs packages keep in /usr/share/doc (doc); every package there is, installed or not (pkg); the entries of Zeal’s docsets (zeal: a function, a class, a method by name, read in place from each docset’s own index, nothing copied); and links to the web (web: the websites of the packages installed, the links the language guides in ~/dev list, and your own in ~/.config/vikix/docs-links, a URL and its title a line). A web hit wears a globe: it is the one kind that opens on the web, and nothing of it is ever fetched, not when the catalogue is read, not when it is searched. Vikix’s guides rank first, then yours, then tldr with the man pages, then the rest of the system’s; a docset’s entry named by words written as code (str.split, read_dir) stands with the documents named by them, and a plain word (keyboard, split) keeps the catalogue’s own hits first, the docsets’ entries after.

A PDF (in a project’s docs/ or at its top, in /usr/share/doc, or in a folder of yours by a *.pdf pattern) is read by the text it carries, its first twenty pages (pdftotext, from poppler-utils; without it a PDF is listed by its name, saying so), a row for the whole and a row a page, so a hit opens at its page (zathura, evince or mupdf take a page; another viewer opens the file). A scanned PDF with no text is listed by its name alone.

It reads again by itself what changed, when a search finds the catalogue more than a day old (a few seconds); vikix update reads the man pages and manuals again; vikix docs watch on reads a document of ~/src the moment it changes. A man page, a tldr page or a Markdown file opens as a page in the docs browser, styled as the guide is (made by mandoc and pandoc, cached in ~/.cache/vikix/docs/); an ArchWiki page as the copy is; a package as a short page (installed or not, how to add it, its website); an Info manual and your notes in Emacs; a Cuis class in a Browser in the running image, through its door (vikix eval –cuis), or its package file in Emacs at the class when Cuis isn’t running; a docset’s entry as its page in the docs browser, at the entry, or in Zeal when the docset keeps its pages compressed; a web link in your default browser. Ctrl+Enter (or –other) opens the other way: Emacs, or a terminal; an ArchWiki page as it is today, on the web; a docset’s entry in Zeal; a PDF’s text in a terminal. vikix docs random opens a guide page at random, every one before any twice.

vikix docs ask answers a question from the documents it finds for it (the words they share), a local model by default, so nothing leaves the laptop unless –claude is said; the answer ends with the documents it drew on, by id. Under an agent, your own documents (own) stay closed to it as they are to docs_search, unless a folder is opened with agents=. The web’s links are never read for an answer, and a docset’s entries are found by name, not asked.

Your own documents (own) are the folders named in ~/.config/vikix/docs, yours to make, a line each: own=~/books (every Markdown file under it), or own=~/books one/*.md two/out/*.html (those files, as patterns from that folder; HTML pages only when asked for). Unlike the other sources they are read a section at a time (a Markdown heading, an HTML heading with an id or a data-at tag), so a search lands on the section, and so does a chapter a page of vikix what names. They open in the docs browser at that section, styled as the guide is, or in Emacs. They are closed to agents: docs_search and docs_read leave them out, unless a line agents=~/books opens that folder to them. The same file names the folders of your own pages for vikix what (what=FOLDER; vikix what help says what a page is).

The catalogue is one SQLite file, ~/.local/share/vikix/docs/index.db: table docs (id, source, kind, title, path, excerpt, mtime) and docs_fts, its full-text index. Nothing in it leaves the machine.


23.16 vikix-docs-open

Open guides, tutorials and offline docs in the docs browser.

The docs browser is Nyxt when it’s installed (the feature lisp-apps): a browser written in Common Lisp, changeable in Lisp as StumpWM is, so the guides can grow keys and pages of their own there. The rest of the web stays with your default browser (xdg-open, ~/.config/mimeapps.list). Without Nyxt, this is xdg-open.

~/.config/vikix/docs-browser, if you make it, names another program to use instead: one word on a line, such as firefox, chromium or xdg-open.

A running Nyxt takes the pages as new buffers in its window (Nyxt hands them over through its socket), and StumpWM then brings that window forward, from whichever workspace it’s on.


23.17 vikix-doctor

Check the pieces are all there, and mend the plain faults.

What –fix mends is what has one safe answer and is Vikix’s own: a link Vikix made that is broken, gone or points elsewhere (made again, what was there moved to NAME.vikix-bak.TIME), a runit service of services.list not enabled (sudo), ~/.slime-secret or ~/.config/vikix/secrets with the wrong mode (chmod, nothing read), the Info manual or the man pages older than the guides or the commands (install/40-config.sh run again, which makes them), and the plugins behind the pin (vikix plugin sync). Each check says so itself as it fails, so the plain run’s last lines list exactly what –fix would do on this machine. Nothing of yours is touched beyond its mode: a missing program is vikix update’s, a key in the wrong place is yours to move (vikix ai key), and a fault it only names is left to you.

It exits 1 when anything is wrong, fixed or not: run it again after –fix to see it clean. vikix update ends with it (vikix update check), and the MCP tool doctor is it too.


23.18 vikix-door

The Lisp agents sent that the door held, and what passes.

The door (config/stumpwm/vikix/door.lisp) stands between an agent and the running desktop. An agent’s Lisp (vikix eval under Claude Code or another agent, the MCP server’s eval tool) is read without running anything and walked: every function it calls must be on one list, of what reads the desktop and what is put back as easily as done. A form that runs a program, touches a file, defines or changes code, sets a global or waits on the desktop is held here instead, and the agent is told why. Super+m, Door is the same list in a menu. Your own vikix eval isn’t checked.

Your own names go in ~/.config/vikix/door, one a line (# for a comment): a function of your user.lisp that an agent may call. The count (used) is kept with the keys’ in ~/.local/state/vikix/used: names and numbers only, never a form’s text; vikix used forget starts it again.


23.19 vikix-drives

USB drives: mounted when plugged in, ejected from a menu.

udiskie calls back for two things: password DEVICE (the rofi prompt) and event EVENT MOUNT_PATH. On a mount, if it’s the drive vikix backup setup chose and a backup is due, the backup starts by itself.

Drives are what udisks mounts for you, under /run/media/$USER.


23.20 vikix-dropbox

Dropbox as one short line, for the mode line.

dbx ↓1,204 ↑3   syncing: files left to download, and to upload
dbx sync        syncing, with no count to show
dbx paused      syncing is paused
dbx …           starting, connecting or indexing
dbx !           it can't sync, and says why in `dropbox status`
dbx off         set up on this machine, but not running

Prints nothing while it’s up to date, when Dropbox isn’t installed, or before it was ever set up here (no ~/.dropbox), so the bar leaves the field out. dropbox status asks the daemon over a socket, with a time limit: a stuck daemon must not hold up the bar.


23.21 vikix-esploro

Esploro, Vid’s file explorer.

Esploro, Vid’s file explorer (github.com/vukini/esploro): a frame of Emacs, on dired, with menus, a tool bar, the mouse and drag and drop; its core, which does every change to files (journaled, so it can be undone), is Common Lisp, and knows which window has each file open.

Command: esploro [FOLDER] (through Emacs’s server: Vikix runs Emacs as a daemon); Super+e opens it, or goes to its frame; it’s in the launcher (Super+d) and Super+m, Apps; M-x esploro in Emacs once it’s been opened.


23.22 vikix-eval

Run Lisp inside the running StumpWM and print the result.

The forms are read in the STUMPWM package, so Vikix’s and StumpWM’s own names work without a prefix. For each form it prints what the form printed, then "=> " and the value.

It talks to Vikix’s own socket, $XDG_RUNTIME_DIR/vikix.sock (VIKIX_SOCKET names another; config/stumpwm/vikix/socket.lisp serves it, 0600 in a folder that is yours alone, so nothing is sent to prove who you are), where a form that only reads the desktop’s state is answered by a thread of its own, even while a menu is open, and anything else goes to the main thread as before. Without the socket (an older desktop, a session without elogind) it talks to the Swank server that swank.lisp starts on 127.0.0.1:4004 (VIKIX_SWANK_PORT changes the port). When ~/.slime-secret exists (40-config makes it), Swank lets in only a client that sends its first line first, as Emacs’s SLIME does; so does this. The Lisp side, vikix-eval-for-agent, catches errors, so a bad form prints "error: ..." instead of leaving this command waiting.

Exit status: 0 when every form ran, 1 when one failed, 2 when StumpWM could not be reached, 3 when the door held the forms.

The door (config/stumpwm/vikix/door.lisp). When an agent is above this command in the process tree (Claude Code, Codex, OpenCode, Gemini, Aider or Antigravity, with no script of Vikix’s between: vikix theme run by an agent sends Vikix’s Lisp, not the agent’s), the forms are an agent’s, and the desktop walks each before anything runs: every function it calls must be on the door’s list (vikix door allowed). A form that runs a program, touches a file, defines or changes code, sets a global or waits on the desktop is held for the user instead (Super+m, Door; vikix door), with why printed here. Your own vikix eval at a terminal is yours and isn’t checked. The door stands only at the desktop’s own Swank (port 4004): a test’s StumpWM on another port asks for it with –door.

Changes made this way live in the running StumpWM only. They are gone after a restart or a reload; to keep one, put it in ~/.stumpwm.d/user.lisp.

The Cuis door (–cuis; cuis/VikixServer.pck.st, loaded by vikix cuis setup) takes the same first line of ~/.slime-secret, then lines ending with a line of one dot (a line starting with a dot gets one more), and answers "ok" or "error", the lines of the answer the same way, and a dot. An agent’s expression (or anyone’s with –door) goes with a first line "door: WHO", and the image’s walker (VikixWalker) parses it and checks every global it names and every message it sends against its lists before anything runs; one that runs a program, touches a file, evaluates text, reaches the system, defines code or waits is held in the image (VikixServer held; the user runs it there with VikixServer runHeld: N, or drops it), with a notification here and exit 3, as the Lisp door holds.


23.23 vikix-features

What you add to Vikix beyond the base.

What you add to Vikix beyond the base (vikix add, vikix remove, vikix features).

A feature is a line in features.list (a language, an editor, LibreOffice, printing, Windows, local AI ...); a bundle, in bundles.list, is several (essentials, developer, everything). Your choices are the lines of ~/.config/vikix/features. Your own files are never touched: ~/dev, your editor configs, a Windows VM’s disk (vikix windows remove asks for that).


23.24 vikix-fingerprint

A fingerprint for sudo and the lock screen.

With it on, your password works exactly as before. To use the finger instead, press Enter at the password prompt (sudo’s, or the lock screen’s) with nothing typed, then touch the reader. Over SSH the reader is never asked.

fprintd does the work; it only knows the readers libfprint has a driver for (fprint.freedesktop.org/supported-devices.html). With no such reader, this says so and changes nothing.


23.25 vikix-firewall

The firewall, ufw.

Replies to what this computer asked for always come back in: web pages, updates, mail. A rule is only needed for a program others connect to. Printers and other devices that announce themselves (mDNS, as avahi uses) are let in by ufw’s own rules, and the VMs on libvirt’s network by libvirt’s. Ports opened by on when the program is there:

LocalSend   53317 (tcp and udp), to send files to and from a phone

ufw keeps everything in /etc/ufw, and its runit service puts the rules back at boot. Every change asks for your sudo password.


23.26 vikix-firmware

Firmware updates from LVFS, through fwupd.

Laptop makers, Lenovo among them, publish BIOS, Thunderbolt, dock and fingerprint-reader firmware on LVFS (fwupd.org). fwupd itself starts when asked (D-Bus); there is no service to switch on. The bar says "firmware" when an update is waiting: vikix-updates checks every 6 hours.


23.27 vikix-font

The one font file StumpWM draws its bar, menus and messages in.

StumpWM’s TrueType module (ttf-fonts) reads only single .ttf files, and Void’s font-iosevka ships Iosevka as .ttc collections of every weight. So this takes Iosevka Regular out of the collection (with fontTools) into

~/.local/share/vikix/fonts/wm.ttf

which theme.lisp loads. Until Iosevka is installed (fonts.list, in the base), wm.ttf is a link to Noto Sans Mono instead. The folder is outside fontconfig’s paths, so other programs don’t see a second Iosevka.


23.28 vikix-gestures

A three-finger swipe on the touchpad moves the focus.

A three-finger swipe on the touchpad moves the focus; two fingers on a touchscreen walk a strip (vikix gestures).

Three fingers swept left or right go to the window that way, as Super+h and Super+l do: along a strip (vikix viri), a column at a time, and between the splits of a tiled workspace. Swept up or down, they go up and down a column or the splits. A long sweep goes on going: a step for each stretch of the way. The direction is the one your touchpad scrolls in: where scrolling isn’t "natural" the focus goes the way the fingers do, fingers to the left to the window on the left; where it is, they bring the next window on the right, as they move a page. (Two fingers swept sideways walk along a strip too: that is the strip’s own, *viri-scroll-walks*.)

On a touchscreen, two fingers dragged sideways over a strip walk it, a column for each stretch, the way they drag: fingers to the left bring what’s on the right. The X server hands every touch to this listener first (a passive touch grab on the root window), which decides at once: a two-finger sideways drag over a strip is its own, and the program under it sees nothing; one finger, three, fingers going up or down, a tap, or anything over a tiled workspace goes to the program as if nothing were listening (one finger held still for 0.15 s goes too, so a long press reaches it). StumpWM says which it is in _VIKIX_STRIP on the root window (viri.lisp). Stylus touches aren’t taken.

Settings are yours, in ~/.config/vikix/gestures, one a line:

fingers = 3      how many fingers make the sweep (3 or 4)
pan = 150        on a touchscreen, over a strip: a column for each PAN
                 pixels two fingers drag sideways; pan = no leaves the
                 screen alone
distance = 120   how far they go for each step: less is quicker
natural = no     yes: fingers to the left bring what's on the right;
                 not said, it is as your touchpad scrolls

It listens through the X server (XInput 2.4, touchpad gestures), so it needs no group or password; a program that takes the sweep for itself keeps it. It is off while ~/.config/vikix/gestures-off exists, and stops by itself on a machine with no touchpad.


23.29 vikix-grok

Local task briefs and reviewed results for Grok Bot.

Tasks are local, in ~/.local/share/vikix/grok/tasks.db (private, backed up). VIKIX_GROK_DIR overrides that directory. Creating a task sends nothing; paste its prompt into Grok Bot and approve its local commands. The Bot returns summary, sources, artifacts, and questions as JSON. Sources and artifacts are HTTP(S) links, never automatically fetched or executed. States: queued, running, review, accepted, failed, cancelled. There is no automatic retry, remote API, service, or Office worker launched by this helper. A failed task remains readable; create a new task to retry it. Keep Grok’s local execution policy at Ask every time. This helper is a handoff convention, not a sandbox around Grok’s other local commands.

Grok Bot comes as a .deb, an .rpm and an AppImage; Void has none of their tools, so install asks xAI’s release list for the current .deb, unpacks its app folder (/opt/Grok Bot) with Python alone and links the program: nothing of the package runs while it is put in, and nothing outside your home is touched. Unpacked, it can’t update itself: install again brings the release of the day. vikix add grok-bot is the same as a feature.


23.30 vikix-hype

Hype, Markdown presentations with a visual slide editor.

Hype, Markdown presentations with a visual slide editor (https://github.com/omacom/hype, by DHH; MIT). Made for Omarchy; Vikix gives it what it looks for there: the desktop’s colours, themes to choose for the slides, and the desktop portal for its file dialogs.

Then: hype open talk.md (or Super+d, Hype), hype help for the rest.

The colours: Hype’s window follows vikix theme as it changes, and every Vikix theme (yours too) is a theme to choose for the slides. vikix theme writes them in Omarchy’s form: ~/.local/state/omarchy/current/theme/ colors.toml (the current one, where Hype looks) and ~/.local/share/vikix/omarchy/themes/NAME/colors.toml (the hype command sets OMARCHY_PATH there).


23.31 vikix-idle

What happens when you leave the computer alone.

after LOCK minutes       the screen locks (xss-lock runs vikix-lock)
after SCREEN_OFF minutes the screen goes dark
after SUSPEND minutes    on battery only, the computer suspends

The times are minutes, from ~/.config/vikix/idle when it exists, e.g.

LOCK=10
SCREEN_OFF=11
SUSPEND=20          # 0: never suspend by itself

Anything not set there keeps the value below. Critical battery sleep is separate: vikix-battery still suspends at 5%, even with keep-awake on or SUSPEND=0.


23.32 vikix-image

Open an image in nsxiv together with the rest of its folder.

Given one file, nsxiv shows only that file. This hands it every image in the same folder, in name order, starting at the one asked for, so n / p (or the arrow keys) move on through the folder and Enter shows them all as thumbnails. Given several files, it opens just those.

xdg-open and the file managers use it through vikix-image.desktop, which ~/.config/mimeapps.list names for images.


23.33 vikix-jupyter

JupyterLab in ~/dev, with the Python that 67-dev set up.

Started by jlab, the launcher (s-d: type JupyterLab, or jlab) or the menu (s-m). If a JupyterLab is already running, its page is opened again rather than a second one started. The server’s messages go to ~/.local/state/vikix/jupyter.log.


23.34 vikix-keyboard

Apply the layout and options in ~/.config/vikix/keyboard.

Run at login by vikix-session; run again after editing the file.


23.35 vikix-lazarus

Start Lazarus: the docked IDE that 65-languages builds in ~/.lazarus.

Start Lazarus: the docked IDE that 65-languages builds in ~/.lazarus (one window, which StumpWM tiles), or Void’s plain one if that build isn’t there. Void’s startlazarus would pick the plain one. config/applications/lazarus.desktop runs this, so the launcher (Super+d) and opening a .lpi file both come here.


23.36 vikix-learn

Courses in the terminal.

Courses in the terminal (vikix learn): every lesson is a real program you edit, save, and watch get checked.

In the lesson pane: the arrows, PgUp/PgDn and Space scroll; n or Right the next lesson, p or Left the one before; h a hint, c check now, r reset, q quit. It remembers the lesson and where you were in it, and opens there.

The course comes from Vikix (learn/COURSE/ in the checkout). Its lessons are copied to ~/learn/COURSE/ the first time: those are your files, never overwritten (but lesson.md, the text, which follows Vikix’s), and in your snapshot history (vikix undo). The checks stay Vikix’s, so a fix to one reaches you with vikix update. Your progress is in ~/.local/state/vikix/learn/COURSE/.

This knows nothing about any language: a course is a folder with a course.conf (TITLE, and WORK, the files you work in) and lessons NN-name/, each with lesson.md, the files to copy, a check.sh and hints.md; a lesson whose work is in other files names them in its own file "work". A course that renames lessons lists them in "renames" (OLD NEW a line): your folders and progress move with them.


23.37 vikix-ledger

What left this laptop, by program and destination: the outbound ledger.

The site says nothing leaves the laptop unless you ask; this is how anyone checks. The firewall (ufw) logs every new outbound connection, not on the loopback, with the user id, into the kernel log socklog keeps (/var/log/socklog/kernel/current, readable by you). The watcher tails that log and, for each line, asks ss which program holds the socket’s port (its name, its executable, its folder, and whether it is an agent or an agent’s child: claude, codex), then records the connection in the records store (vikix records, plugin ledger, kind connection): one record a day for each program, destination and port, with a count and the first and last time. Who talked to whom and when: no payload is ever kept, and a destination is an address and its name when one resolves.

A program that is gone before ss is asked (a quick DNS query) is recorded as "?" with its user. The rule is a block in /etc/ufw/after.rules and after6.rules, before their COMMIT, as vikix firewall keeps ufw’s own; it logs at most a hundred new connections a second. ~/.config/vikix/ledger says it is on; the session starts the watcher when it is.


23.38 vikix-lisp-apps

Programs written in Common Lisp, and programmable in it, as StumpWM is.

Programs written in Common Lisp, and programmable in it, as StumpWM is: Nyxt (a web browser), Lem (an editor) and McCLIM’s Listener (a Lisp prompt whose output is live objects), with Clouseau, the inspector.

Commands: nyxt, lem, clim-listener; all three are in the launcher (Super+d).


23.39 vikix-local-ai

AI models that run on this machine, with Ollama.

Its API is on http://127.0.0.1:11434 (only this machine; the Windows VM can’t reach it). The bar says "ai" while a model is loaded in memory. Models are big: they’re in ~/.ollama/models, and backups leave them out.

Honest about a laptop without a graphics card. Measured on an i7-7500U with llama3.2:3b: about 4 s to load, then about 11 s for two sentences. Models of 1-2 billion parameters are about twice as quick, 7-8 billion about three times as slow; bigger ones don’t fit.

A graphics chip that shares the main memory (AMD’s Ryzen AI Max: 128 GB, of which the chip may take 65) runs a model many times faster than the CPU, and holds ones a CPU can’t: Ollama leaves such a chip out unless asked (OLLAMA_IGPU_ENABLE=1), so serve asks when graphics= in ~/.config/vikix/ai says on, or says nothing (auto) and the chip may take 32 GB or more; off keeps the CPU. Measured on the Ryzen AI Max+ 395 (2026-10-19, Ollama 0.34.4): gpt-oss-120b answers at 51 words a second through Vulkan, 35 through ROCm (which sees 61 of the chip’s 65 GB and leaves 9 GB of the model on the CPU), so Vulkan it stays. Ollama’s own context there is the model’s longest (4.6 GB more for gpt-oss-120b), which once took the whole of the chip’s memory: the X server, refused its share, ended the session (three times that day). So serve sets a 32k context (OLLAMA_CONTEXT_LENGTH; a request may still ask for more) and keeps 8 GB from Ollama’s sums (OLLAMA_GPU_OVERHEAD), which stop it loading a second model beside. llama-server’s own margin (LLAMA_ARG_FIT_TARGET) is no help on such a chip: what it moves to "the CPU" is memory the chip maps all the same, and it only cost speed (44). The 120B leaves the desktop about 3 GB there until the kernel’s share is raised. The picker counts that memory and rates the models that fit in it by the parameters at work on each word (lib/ai-models.tsv).

The kernel lets such a chip take half of the memory (TTM’s page limit) until told otherwise. share most writes a block into /etc/default/grub (ttm.pages_limit and ttm.page_pool_size in 4 KiB pages, amdgpu.gttsize in MiB: all but 16 GB) and runs update-grub, so from the next boot the chip may take most of it, which the biggest models need; half takes the block out. setup offers it on such a machine, asking first, since it changes how the machine boots. The picker reads the chip’s share as the kernel gives it, so it follows the next boot by itself.


23.40 vikix-lock

Lock the screen, with only ever one locker.

The session runs xss-lock, which starts vikix-lock --locker after 10 idle minutes and before a suspend. The key (s-Escape) and the menu run plain vikix-lock, which asks xss-lock to lock now: a second i3lock started beside xss-lock’s would need unlocking twice. Without xss-lock (another session), it locks by itself.

The lock screen is i3lock-color: the wallpaper (the one showing, through vikix-wallpaper which), a clock and the date, and a ring that shows what is typed, in the theme’s colours (vikix theme writes them to ~/.config/vikix/theme/palette). The ring is the accent; a key lights it in the foreground, backspace in the alert colour; while the password is checked it goes subtle, and wrong turns it the alert colour and says so. With plain i3lock instead, a screen in the theme’s background colour.

While the screen is locked, notifications wait: dunst draws its windows above everything, i3lock’s too, so a message could be read on a locked screen. They are shown once it’s unlocked, unless they were already paused (Do not disturb), which is kept.

A key that wakes the dark screen isn’t kept as part of the password.


23.41 vikix-mcp

The Vikix desktop as an MCP server, for any agent that speaks MCP.

The Vikix desktop as an MCP server, for any agent that speaks MCP (Claude Code, Antigravity CLI, Codex, Gemini CLI, OpenCode).

Why: your agent can already run commands, but each needs your yes. These tools are a small, checked set: allow them once (in Claude Code, "always allow" for vikix), and the agent can look at the desktop and make small, undoable changes without asking each time, while other commands still ask.

The tools, a fixed set:

read only   desktop (workspaces, windows, screens, theme), keys, commands
            (the desktop's commands an agent may run), rules (the
            desktop's rules, and why a window is where it is), why (what
            the desktop did lately, and what made it), agents (the
            agents at work on the desktop, and what each is doing),
            office (tasks and desks), tasks (the task records), handoff (a desk's record),
            doctor, history, changes, themes, cuis_state (the Cuis
            image: installed, running, what it shows), version
small acts  notify, snapshot, set_theme, switch_workspace, focus_window,
            run_command: each checked against what's there, and easy to
            take back. run_command runs one of the desktop's own commands
            by name, and only those its registry marks for agents
            (registry.lisp, :agent t: do not disturb, night light, gaps,
            focus left ...); the desktop refuses any other
proposals   propose_file_changes (a plan shown in Esploro) and
            propose_rule (a rule shown under Super+m, Rules): checked
            whole, and only your choice there changes anything
off unless  eval (Lisp in the window manager, through the door) and
switched on  cuis_eval (Smalltalk in the Cuis image, through its own
            walker: --allow-eval), and undo (your files back a snapshot:
            --allow-undo). These are a convenience, not a wall: an agent
            that can run commands can run vikix eval, or register the
            server again, itself; the doors stand on that road too.

Nothing an agent sends reaches Lisp or a shell except as a value checked against the desktop (a workspace that exists, a theme there is, a number), or, for propose_rule, as text the window manager reads without running and holds until you decide; eval’s form is read the same way and walked by the door (door.lisp) first, and runs only when every function it calls is on the door’s list, else it waits for you (Super+m, Door; vikix door); cuis_eval's expression the same way by the image’s walker (VikixWalker), and waits there (VikixServer held) when it may not run. Every call, refused ones too, is logged in ~/.local/state/vikix/mcp.log (600): the tool, whether it worked, its arguments (secrets taken out, long ones cut, with their length and a hash).


23.42 vikix-memory

What uses the memory, what’s left over, a warning when it runs low.

Left over means nobody can be using it:

for sure   a program on a hidden screen (Xvfb) whose starter has gone, or
           on a screen that no longer exists, or a test's program whose
           home is a temporary folder
maybe      a program an AI agent's command started and left behind, one
           whose folder was deleted, an editor with no window

and always: its starter has gone (it belongs to nobody), it has no terminal, no window on your screen, and it’s older than 10 minutes, so a test that’s running is left alone.

The last resort is earlyoom, a system service Vikix switches on: when memory is all but gone (5% free, and a quarter of the swap used) it ends one program rather than letting everything stall: a test’s or a build’s first (Xvfb, sbcl, compilers), then the biggest of the rest, an AI agent’s session, the browser itself and a virtual machine only when nothing else is left, and never the desktop (Xorg, StumpWM, Emacs, sound, a terminal). The watcher says what it ended. /etc/sv/earlyoom/conf is Vikix’s (config/earlyoom/conf).

VIKIX_MEMORY_LOW and VIKIX_MEMORY_CRITICAL change the two levels (percent free), VIKIX_MEMORY_LEFT_AFTER the minutes; VIKIX_MEMORY_AUTOCLEAN=0 keeps the watcher from ending anything.


23.43 vikix-music

A Lisp musical sketchpad, with SuperCollider making the sound.

Patterns are yours, ~/music/first-song/patterns.lisp to begin with. Use (tempo 120) and (defpattern bass ’(c4 - e4 -)); - is a rest. Files are read as data, never evaluated. A bad edit keeps the last good pattern. Optional (bank 1 bass) saves pad assignments (slots 1–32); without a bank, pads use file order. Edit assignments in the browser, with snapshot undo. Patterns optionally take :sound ’sine|kick|snare|closed-hat|bass|bell, :gain 0..1 (relative to session gain), and :swing 0..0.5 (even step counts). Drums use x hits and - rests; melodic x remains 220 Hz. The browser edits these data fields with undo. Session gain stays at 0.08 by default, capped at 0.1. Run setup again to compile the palette after an older Music install. Progressions use (defprogression verse ’(I (vi 2) - V) :key ’f): major uppercase/minor lowercase triads, whole-bar blocks and silent rests. The browser edits degrees, key, durations and order with undo; see the Music guide. Snapshot before editing; vikix undo restores patterns at the next bar. The REPL evaluates your Lisp locally. There is no remote evaluation service.


23.44 vikix-net

The network link as one short line, for the mode line.

wifi VID       Wi-Fi: the network's name
wifi VID 42%   and its signal, when it is weak (under 60%)
wired      a cable, and no Wi-Fi
offline    neither

Asks NetworkManager. Prints nothing when it isn’t running, so the bar leaves the field out instead of showing something wrong.


23.45 vikix-network

The Network Office: nearby devices, ports and connections.

ID is the network id from status. New or incompletely identified networks start in manual mode. Discovery checks directly connected IPv4 subnets, at most 1024 addresses altogether; it never sweeps a VPN or an IPv6 prefix. Port checks cover common TCP services, not every port or UDP. They run as you, without sudo. Discovery looks up DNS names and tries Avahi when available. Identify explicitly probes service versions; OS clues are tentative, not OS fingerprints. Ordinary port names are suggestions, not proof of what is listening. Devices can be hidden by a firewall or Wi-Fi isolation; a missing reply does not mean a device is off.

Preferences live in ~/.config/vikix/network/preferences.json. Results are temporary, in the session’s runtime directory, and expire after ten minutes. Friendly names use the network identity and device MAC, never its IP alone. No device history is kept. The session starts watch at login; after an update, log in again for discovery on joins while the Office is closed. Opening the Office applies saved choices too. See the guide’s Network Office page.


23.46 vikix-nightlight

A warmer screen in the evening (gammastep).

The times and colours are in ~/.config/gammastep/config.ini. Switched off, gammastep ends and puts the screen’s colours back; the choice lasts across logins, until you switch it on again.


23.47 vikix-node

A remote Void machine as a node of this Vikix.

A node is reached by SSH alone, as yourself, by key: nothing of Vikix’s is on the node, and ssh HOST is the same machine. Keys only: no password is ever kept or asked after add, so a node without your key says so (ssh-copy-id puts it there). The host key is verified: add shows it for you to confirm, and from then on a changed one refuses. Nothing is sent to a node but what you ask; nothing is synchronised.

The nodes are files, ~/.config/vikix/nodes/NAME (host=, port=, kind=), yours to edit; what each answered last is ~/.local/state/vikix/nodes/NAME, and add and remove are noted in ~/.local/state/vikix/nodes/log.


23.48 vikix-notes

Ask your notes, from any terminal (note for short).

Ask your notes, from any terminal (note for short). A folder of Markdown (an Obsidian vault) is read into an index on this laptop; a question finds the passages nearest it, and a model answers from those alone, naming the notes.

Who answers follows Super+i: vikix ai use local|claude. Locally nothing leaves the laptop; with Claude, the six passages found (never the whole folder) go to Anthropic. The folder and skips are yours, in ~/.config/vikix/notes; the index is ~/.local/share/vikix/notes/index.db. lib/notes.py does the work, run by uv with its libraries pinned at its top.


23.49 vikix-notifications

The notifications dunst has put away, in rofi, newest first.

The notifications dunst has put away, in rofi, newest first. Pick one and it shows again. (s-N, or s-m then "Notifications: earlier ones".)


23.50 vikix-obsidian

An Obsidian vault, converted to Org notes, a folder at a time.

The vault is only read, never changed. Each note becomes an Org file in the same place under ~/Dropbox/notes/vault/, with an ID, so links between notes become org-roam links (C-c n f finds them, backlinks and the graph follow), even to a folder not converted yet: they work once it is. The note’s title, aliases and tags come from its file name and front matter; pandoc does the rest of the Markdown.

What Obsidian has and Org hasn’t is said in the report: a link to a note that isn’t there (or is in a folder left out), a note embedded in another (it becomes a link), ==highlights== (bold), callouts (a quote). Files a note embeds or links (pictures, PDFs, sound) are copied beside the notes, in vault/attachments/, as they are in the vault; only those, not every file in it.

Converting a folder again rewrites its notes, except any you’ve changed since (the report names them; –force rewrites them too).

Settings: ~/.config/vikix/obsidian (vault=, to=, skip=: folders left out).


23.51 vikix-osd

Change volume or brightness and show a bar for it.

The bar is a dunst notification with a progress value. The stack tag makes each new press replace the last bar instead of piling up.


23.52 vikix-palette

Everything in one box (Super+Space).

Enter on a window goes to it, wherever it is; on a workspace, goes there (the ones with windows, and the named ones past the nine); on a command, runs it; on a project, opens it (a terminal in its folder, its log in the editor); on a web app, brings it forward or starts it; on a layout, puts this workspace back as it; on a program, starts it.

A sigil first asks for one kind of thing, and Enter searches instead of picking; the hits fill the box, and Enter on one opens it. The empty box names them (its placeholder: "Type, or > menu @ desks # docs ? what / files"), and the line goes as you type:

> words      the Vikix menu (Super+m), every entry of every section,
             and the commands: Enter runs the one picked
@ words      your projects and the agents' desks: Enter opens the
             project, or goes to the desk's window
# words      the docs catalogue (vikix docs): Vikix's guides, your
             projects' documents and notes, man and tldr pages, the
             manuals; Enter opens the hit, Ctrl+Enter the other way
             (a terminal for a man page, Emacs for Markdown)
? name       what is this: the card for a field of the bar, a key, a
             process, a service, a package, a command or a file (vikix
             what); ? alone lists what the desktop did lately (vikix
             why), and Enter on a line opens Super+?'s choices
/ words      a file or folder under your home folder, by its name (fd:
             the first word is the pattern, the others must be in the
             path; hidden folders and mounted drives left out); Enter
             opens it, Ctrl+Enter shows it in its folder (Esploro, or
             the file manager)

The launcher’s own ! filters its lists by mode (!drun), so no sigil of Vikix’s is !. Super+d is still the plain launcher, programs only. When the desktop doesn’t answer within a second and a half, the box opens with the projects and the programs alone.


23.53 vikix-pkg

Single programs, beyond the features.

A whole language, an editor or LibreOffice is a feature: vikix add and vikix remove. This is for one program: GIMP, a game, a font.

Your skip list is ~/.config/vikix/packages-skip, one package a line; 10-packages leaves those out. Adding a package again takes it off.


23.54 vikix-plugin

Small additions to Vikix, from the vikix-plugins repo.

Small additions to Vikix, from the vikix-plugins repo (github.com/vukini/vikix-plugins) or from a repository of your own: a few words in the bar, Super+m entries, keys, a program started with the desktop.

Vikix keeps the repo in ~/.local/share/vikix/plugins at the commit pinned below, one it has checked: an update can’t swap a plugin’s code in silently. Your plugins are named in ~/.config/vikix/plugins.list, your settings for each in ~/.config/vikix/plugins/NAME (copied once, yours). A plugin from another repository is a line "NAME from REPO at COMMIT" there: the commit is yours to move (vikix plugin pin), its checkout is ~/.local/share/vikix/plugins-from/NAME, and Vikix hasn’t checked its code. A plugin’s programs (its bin/) are linked into ~/.local/bin while it’s added, each with its man page (man inbox). Its Lisp runs inside StumpWM (plugins.lisp loads it).


23.55 vikix-project

Your projects, each a folder with a log.md.

What a project is: a folder under a root (~/src unless ~/.config/vikix/projects says otherwise), at most depth levels down (2), with a log.md in it. A folder inside a project folder is a project of that collection (living-series/living-in-lambda). Hidden folders, node_modules and git worktrees (their .git is a file: they’d count a project twice) are skipped. A public repo keeps its log apart: a repo with no log.md whose name has <logs>/NAME/log.md (logs=~/src/project-logs) is a project with that log.

A log, newest first:

# Log: Title
**Status** (...), as of 2026-09-12: 93% complete.
- Standing: where it is
- Next: what comes next
- Build: make site          (optional: overrides the build found)
- Check: make test          (optional: overrides the checks found)
## 2026-09-18 · status words (Vid)
What was done.
Next: what comes next.

Names match exactly, then by a prefix or a part of the name that only one project has; a collection’s project also answers to collection/name.


23.56 vikix-publish

Books from Markdown.

Books from Markdown: an EPUB and a PDF, built and checked the same way in every project (vikix add publish).

A book is a folder with publish.yml (pandoc’s metadata: title, author, lang; and Vikix’s: name, chapters, mainfont) and its text in chapters/*.md (taken in name order) or book.md. The EPUB goes through pandoc, then the fix for e-ink readers (tables become row cards, one-cell boxes asides: what the doc-to-epub skill learned on a 7-inch screen), then epubcheck; one epubcheck rejects is kept as NAME.epub.rejected, not as the book. The PDF goes through pandoc’s Typst writer, in IBM Plex Serif (Amiri when lang is Arabic, or mainfont in publish.yml), and one Typst warned about is NAME.pdf.rejected. The spelling is the book’s lang (any English is checked as British), and a passage marked ::: {lang=eo} or [vorto]{lang=ar} in its own; code isn’t prose. words.txt beside publish.yml holds the book’s own words, one a line.

A build into out/ is noted in the project’s log (the log.md vikix project knows, when the book is a project): a dated entry, "published", with the files and their sizes. –no-log, or VIKIX_PUBLISH_LOG=0, leaves the log alone.

What this command writes into a book that is in a git repository (its words.txt, a new book’s first files, the log’s entry) it commits, those files alone: nobody else would, and the project would say "not committed" at every push. A file that had changes of yours waiting is left to you, and said; so is everything during a merge or a rebase. –no-commit, or VIKIX_PUBLISH_COMMIT=0, leaves git alone.

In a project’s Makefile, last, the same as make targets (epub, pdf, check):

-include $(HOME)/.local/share/vikix/publish/publish.mk

23.57 vikix-record

Record the screen to a video, without sound.

While it records, the bar says rec. The file holding ffmpeg’s process id is also what the bar reads, so it is removed whenever ffmpeg ends, however it ends.


23.58 vikix-records

Where plugins keep what they found, to search and use later.

The store is one SQLite file, ~/.local/share/vikix/records.db, kept by vikix backup. Any program can read it with SQL: the table is records (id, plugin, kind, key, at, title, body, data, link), and records_fts is its full-text index.


23.59 vikix-rescue

A way out when the desktop is stuck.

vikix eval and the agents’ tools go through StumpWM’s one main thread, so they time out when it is stuck. This asks over the same door (Swank, 127.0.0.1:4004, with its password) but is answered by another thread. It works from any terminal, from a text console (Ctrl+Alt+F2, log in) and over ssh.

On the desktop itself, Super+Ctrl+Alt+Escape does what vikix rescue free does: StumpWM reads that key on a connection of its own, so it works when the other keys don’t. A watcher inside StumpWM tells you when the desktop is stuck, and frees it by itself after a while (rescue.lisp).

Exit status: 0 the desktop is coming round (or was freed), 1 it is stuck or waiting, 2 StumpWM could not be asked.


23.60 vikix-resume

Your windows back after a restart.

The desktop saves each workspace as a layout (which windows, where, and how each was started) in ~/.local/state/vikix/resume/. What comes back is what can be started again: a terminal in its folder with the program that ran in it, a program by its command line, a web app, an Emacs frame on its file. What a program had open inside it is its own to bring back. Super+m has "Bring my windows back" too.


23.61 vikix-rofi

Rofi’s plugin modes, set up the Vikix way.

Both are rofi plugins (rofi-emoji, rofi-calc in packages/desktop.list). Without one, a notification says what to install instead of rofi failing silently.


23.62 vikix-rollback

The system as it was before the last update, in one step.

vikix undo is for your files; this is for the system under them: what vikix update changes. Each record is a folder in ~/.local/state/vikix/ rollback/, named by its time: commit, version, packages (xbps-query -l), changes (what the update was about to do, from xbps-install -un), pkgs/ (those packages’ files as they were, copied from /var/cache/xbps, where they still are at that moment), stumpwm (the binary, when it differs from the record before), and snapshot (snapper’s number, on btrfs). The two newest records are kept.

A restore puts ~/vikix at the record’s commit (off main: the next vikix update goes forward again from there), runs 40-config so the links point where they did, copies the StumpWM binary back, and reinstalls the recorded packages from the record’s files (xbps-rindex makes it a repository; xbps-install -f takes a version down as well as up). A package whose file wasn’t in the cache stays at the new version and is named. Your files aren’t touched: vikix undo is theirs. StumpWM runs the old binary and config at the next login.

On btrfs, with snapper set up for / (snapper list-configs names root), keep also takes a read-only snapshot, and restore says the snapper rollback line (a reboot applies it) rather than doing it: whole-system rollback is snapper’s, and reboots. On ext4 nothing of that is said unless asked (vikix rollback).


23.63 vikix-rules

The desktop’s rules, seen and steered.

The rules are written in ~/.stumpwm.d/rules.lisp (or user.lisp):

(when-window (:class "Firefox") (workspace 2))
(at "09:00" :weekdays (open-project "vikix"))

and live in the running StumpWM, which this asks (vikix eval): the counts are since the last reload, and off lasts until the next one, which reads the files again. Super+m, Rules is the same list in a menu.

An agent doesn’t write your rules: it proposes one (the MCP server’s propose_rule), checked to be a rule made only of verbs and plain values, and the rule waits until you add it or drop it under Super+m, Rules.

Super+Shift+t writes one for you: the rule that puts a window like the one in front where it is (its workspace, and when it floats its size and place), shown first, then added to rules.lisp as "remembered: ...".


23.64 vikix-screens

The screens: a new one lights up by itself, and a menu for the rest.

When a screen is plugged in, autorandr (its udev rule) looks for a layout saved for these screens and puts it back. For screens it has never seen it did nothing: the screen stayed dark. Vikix’s hook (predetect, which autorandr runs first) lays them out instead: the others to the right of the laptop’s screen, each at the largest size it shows at 50 Hz or more (a 4K screen on an HDMI 1.4 port gets 2560x1440 at 60, not 4K at 30), and saves that, so next time it comes straight back. A screen unplugged: the laptop’s alone again. Whatever you pick in the menu is saved the same way, for these screens. A notification says what was done. StumpWM follows by itself.

The layouts are autorandr’s, in ~/.config/autorandr (yours): Vikix’s are named auto-..., and one you save under a name of your own wins.


23.65 vikix-screenshot

Keep a picture of an area, a window or the whole screen.

WHAT    area     drag out an area, or click a window    (Print)
        window   the focused window                     (Ctrl+Print)
        screen   the whole monitor the pointer is on    (Super+Print)
WHERE   clip     to the clipboard, ready to paste
        file     to ~/Pictures/Screenshots/<date>.png   (add Shift)

Text and colour are both in the Super+Ctrl+Print menu. The OCR language is English; VIKIX_OCR_LANG=deu+eng (with tesseract-ocr-deu installed) reads others.

Both words are optional: plain vikix-screenshot is "area clip", and "vikix-screenshot file" is "area file", as before there were three kinds. Escape or a right-click while choosing an area cancels, and nothing is kept.


23.66 vikix-session

Everything that runs for the length of a desktop session.

Started by ~/.xinitrc inside dbus-run-session, so every program here shares one session bus. Without systemd there are no "user services": the background programs are simply started here, and they end when StumpWM (the last line) exits.


23.67 vikix-steam

Steam, with everything a game needs on Void.

Steam is a 32-bit program on a 64-bit machine, and that is why it was a headache on Void: a plain Void has no 32-bit libraries at all, they live in a repository of their own (multilib) that is off by default, and the right ones depend on the graphics card, so one missing library stopped the client, and the next one the first game. This script reads the card from /sys/class/drm (never asks a program), and knows which packages each card wants:

Intel (i915, xe)        mesa-vulkan-intel, mesa-vulkan-intel-32bit
AMD (amdgpu, radeon)    mesa-vulkan-radeon, mesa-vulkan-radeon-32bit
NVIDIA, open (nouveau)  mesa-vulkan-nouveau, mesa-vulkan-nouveau-32bit
NVIDIA, proprietary     nvidia-libs-32bit (470: nvidia470-libs-32bit, 390:
                        nvidia390-libs-32bit), from multilib-nonfree

What every card needs is packages/optional/steam.list, which vikix update keeps. A card not in the table (a VM’s) still gets Steam, and a warning: games that need Vulkan won’t run there.

The limit: Proton’s esync opens an eventfd for every Wine object, and Void’s hard limit of 4096 open files is far too few for a game, so the setup writes /etc/security/limits.d/50-vikix-steam.conf with 524288 for you (the hard limit only; programs raise their own soft one). It takes effect at your next login. Game controllers need nothing: steam-udev-rules tags them for the seat, and elogind hands them to whoever is logged in.

Steam’s own files are yours: ~/.local/share/Steam (the client, the games; tens of GB) and ~/.steam. Nothing here deletes them.

For the tests: VIKIX_DRM stands in for /sys/class/drm, VIKIX_LIMITS_DIR for /etc/security/limits.d.


23.68 vikix-theme

The colour theme, everywhere.

A theme is a file of named colours: themes/NAME.theme in Vikix, or your own in ~/.config/vikix/themes/. Switching remembers the choice and writes the colours out for each program into ~/.config/vikix/theme/, which your config files include; the programs that are running pick the new colours up now (StumpWM, dunst, kitty, the editors, Nyxt, GTK and Qt, Cuis), and the theme’s own wallpaper comes with it. Super+m → Theme is the same, with each theme shown as you move to it. An agent’s TUI (Codex, Claude Code) is the exception: it reads the terminal’s background once, as it starts, so a switch between a light theme and a dark one names the agent sessions running, which keep their colours until started again. vikix (the everyday command) hands vikix theme over to this script.


23.69 vikix-times

How long the desktop takes.

The limits are lib/times.limits; tests/times.sh fails above them.


23.70 vikix-updates

What vikix update would bring.

What vikix update would bring: Void packages with a newer version, and new Vikix commits; and firmware updates waiting on LVFS (vikix firmware update installs those). The bar shows it (modeline.lisp).

The result goes to ~/.local/state/vikix/updates as "PACKAGES COMMITS FIRMWARE TESTS", with ? for a count that couldn’t be checked (offline, say). TESTS is GitHub’s verdict on the commit this machine runs: ok, failed, running, ? when it couldn’t be asked, or - on the good channel, where what runs has passed by definition. A machine on main takes every commit before its tests, so the bar says "tests failed" when they do, within ten minutes, and a notification says it once per commit. Checking takes a few seconds of network, so it happens here, in the background, and the bar only reads the file.


23.71 vikix-used

What gets used: the keys you press and the commands you run.

The desktop counts each key that runs a command, each entry picked in Super+m and the other menus, each pick in the palette (Super+Space), each command typed after Ctrl+t ;, each rule that runs, each command an agent runs, and at the door (vikix door) the names an agent’s Lisp calls, the name that held a form and whether you ran or dropped it. It keeps names and numbers only: the key, the command it is bound to, the entry’s words, and when each was first and last used. Never a window’s title, never what you typed into a program or after a command’s name.

The counts are in ~/.local/state/vikix/used, a text file that is yours to read or delete. Nothing sends it anywhere. They are written every five minutes and when the desktop ends.


23.72 vikix-versions

Every version of a file, from both histories, and one brought back.

Vikix keeps two histories of your files. vikix backup holds daily, weekly and monthly versions of all of ~ (restic, encrypted, on a drive or a remote); vikix snapshot holds every change to your settings, the files ~/.config/vikix/yours.list names (git, in ~/.local/state/vikix/yours.git). This is the one window onto both: the list, from the file, and a restore that never overwrites unless you say –replace, and then only through the Trash. The list is kept for a minute in ~/.cache/vikix/versions/, since restic takes a few seconds over a year of backups on a USB drive. A backup whose content is the one before it (same size and time) is folded into that row, which then says from when to when; a snapshot is one row per change. A folder’s version is everything under it (its size is theirs together), folded the same way.

A restore beside writes NAME (Mon 29 Sep).ext next to the file, or NAME (Mon 29 Sep, 2).ext when that is taken; a folder comes back as NAME (Mon 29 Sep)/. –replace puts the current one in the Trash (gio trash), then the version in its place; what the Trash holds comes back from there (Esploro, or gio trash –restore).


23.73 vikix-vm

Virtual machines: every one libvirt has, in a menu.

A VM that is paused keeps its memory but uses no processor; a saved one uses neither, and starts where it was. The Windows VM (vikix windows) opens as vikix windows does, so its checks run. The system’s libvirt answers when you are in the libvirt group; when it doesn’t, only yours are listed. Nothing here needs sudo.


23.74 vikix-voice

Talk to the AI, and it talks back.

Talk to the AI, and it talks back. Dictation writes down what you said (on this laptop, whisper.cpp); this sends it on, and Piper reads the answer aloud (a neural voice, on this laptop too).

Super+F10         speak, Super+F10 again: the chat model answers
                  (Super+i's: local, Claude or Codex), shown and
                  spoken. Follow-ups carry on the conversation; after
                  5 quiet minutes (idle= below) the next one starts
                  afresh. Codex answers each question on its own
Super+F11         speak, Super+F11 again: it goes to the agent (Claude
                  Code) in its own terminal; follow-ups go to the same
                  one, and Claude's replies are read aloud
Super+Shift+F10   stop talking

The choices are yours, in ~/.config/vikix/voice (made on first use): the voice, speak=no to only show answers, idle= minutes. The chat’s words go where Super+i’s do (vikix ai use local|claude|codex); the agent’s go to Anthropic, as with Super+a. What’s said aloud stays on this laptop.


23.75 vikix-wallpaper

The picture behind the windows.

Unless you choose otherwise, the wallpaper cycles: every picture once, in a shuffled order, before any comes again, and one you add is shown next, from Vid’s collection (the feature wallpapers, in ~/.local/share/vikix/wallpapers, which a fresh install has), ~/Pictures/Wallpapers and ~/wallpapers (put yours in either). The one showing is remembered in ~/.local/state/vikix/wallpaper-now, the round in wallpaper-queue and wallpaper-shown beside it, the minutes in ~/.config/vikix/wallpaper-minutes.

Following the theme (~/.config/vikix/wallpaper-theme), its own picture is the one next to its theme file with the same name (themes/vikix-dark.jpg, or ~/.config/vikix/themes/mine.jpg beside mine.theme), so vikix theme changes it too. A theme without a picture gets a plain background in its own colour; so does cycling with no pictures to cycle. Your choice is ~/.config/vikix/wallpaper, a link to the file; off is ~/.config/vikix/wallpaper-off. Each choice ends the others.

The picker lists the theme’s, Cycle, then all the pictures; its last entry is off.


23.76 vikix-wallpapers

More wallpapers: Vid’s collection, a git repository.

More wallpapers: Vid’s collection, a git repository (github.com/vukini/wallpapers), kept beside Vikix rather than in it, so the checkout stays small and a fresh install needs no pictures from the network.

The wallpaper cycles through them (vikix-wallpaper), and they show in the picker (Super+m, Wallpaper) beside ~/Pictures/Wallpapers and ~/wallpapers. A fresh install adds them. VIKIX_WALLPAPERS_REPO names another repository. If ~/wallpapers is already a clone of it (your own working copy), the folder is a link to that, and Vikix never pulls into it.


23.77 vikix-webapp

A website as a program of its own.

Each one is a Chromium window with no tabs and no address bar, with its own window class (vikix-NAME), so StumpWM can find it on any workspace, and its own profile in ~/.local/share/vikix/webapps/NAME: work logins stay apart from personal ones, and from your everyday Firefox. Its notifications come through dunst while its window is open.

The camera and microphone: a web app’s window has no address bar, so Chromium’s "allow camera and microphone?" is easily missed, and a meeting’s settings then show every device greyed out. A web app with media on (a .vikix-media file in its profile) has both allowed for its own site, written into its profile as it starts (Chromium rewrites that file while it runs, so never before).

Your list is ~/.config/vikix/webapps (one "NAME URL [KEY]" per line; your own # comments are kept). StumpWM reads it (webapps.lisp) for the keys, the key help and Super+m.


23.78 vikix-welcome

The welcome: first steps on a new desktop, in a terminal, each ticked off once done.

StumpWM opens it by itself at the first login (commands.lisp), and Super+m, Welcome brings it back. What’s done is kept in ~/.local/state/vikix/welcome, one step a line; that it exists means the welcome has been shown.

The pickers are fzf, which the base installs: type to narrow the list, Tab to pick several, Enter to go, Esc to go back.


23.79 vikix-what

What is this? A part of the running computer, on a card.

Super+Alt+? is the same on the desktop: point at a field of the bar and press it, or press it with a window in front. A click on a field that does nothing else when clicked (the battery, the clock, updates) opens its card too.

A card has three depths. First what this very thing is doing now, read a moment ago: a process’s memory and what started it, where a key is written and how often you press it, what a field of the bar shows and where that comes from. Then a short paragraph on what such a thing is. Then the explanations, the nearest first: the section of Vikix’s guide, the manual page, the file it is written in, and the things beside it (a window’s process, a process’s package).

The paragraphs and what each kind points at are pages, a file a kind: the paragraph, then lines such as guide: fixing.md#The desktop feels slow, manual: ps(1), source: bin/vikix-net and see: process. Vikix’s are in its config/what. Yours are in the folders ~/.config/vikix/docs names with what=FOLDER (process.md, service.md, and service-sshd.md for one thing by name, which falls back to service.md): your paragraph replaces Vikix’s, your lines come first, and yours may say chapter: PATH#HEADING, a section of one of your own documents (a folder an own= line there names, which the catalogue reads a section at a time; vikix docs help), opened as the catalogue opens it. A window’s title and whatever you pointed at are shown on the card and written nowhere.


23.80 vikix-why

Why did that happen? What the desktop did lately, and what made it.

A window jumped to another workspace, a key did something odd, the layout changed under you: the desktop notes the key pressed and the command it ran, each rule that runs and the window it ran for, the menu’s entries, what an agent or a script asked for. The same thing again is one line, counted (×3). It is kept in the running desktop only, fifty at most, until StumpWM starts again; nothing is written down.

Super+? shows the same list on the desktop. Pick a line there and it offers what can be done: edit it where it is written (user.lisp, line 42, in Emacs), take it back when it is a switch or changed the layout, bring a window a rule moved here, switch the rule off until the next reload.


23.81 vikix-wifi

Wi-Fi: pick a network from a list that is scanned first.

The list is only as fresh as NetworkManager’s last scan, which is what the tray’s applet shows, often stale: NetworkManager scans on its own now and then, so a recent stamp is no sign the list is right. So the picker scans every time it opens, waiting five seconds at most (a notification says so; what the scan has found by then is shown), and "Scan again" scans once more. The line over the list says when NetworkManager last scanned, so a scan it refused (one asked too soon after the last) or one still going shows as what it is.

A new network’s password goes to NetworkManager through a file of your own (0600, deleted at once), never on a command line. A network that can’t be joined this way (WEP, a login with a user name) is sent to nmtui. A password refused leaves nothing saved.


23.82 vikix-windows

Windows in a VM, for the programs that only run there.

The VM runs as you (libvirt’s qemu:///session), so its disk, its TPM and its shared folder are all yours, in your home. ~/Windows is drive Z: in Windows, and vikix backup covers it; the VM’s disk it leaves out. The display is SPICE with no network port: only this user can open it.

Its network is private: libvirt’s NAT bridge, virbr0 (through qemu-bridge-helper): Windows reaches the internet, and sees this machine only as 192.168.122.1, where nothing that listens on 127.0.0.1 alone can be reached: Swank, CUPS, a local model. (passt, the first network, handed Windows this machine’s 127.0.0.1 as its gateway address.)