What vobuda does with your machine
Everything the program touches outside its own settings folder, written down so you can check it. The settings folder is ~/.config/vobuda, and vobuda where prints it.
No account, and nothing sent unless you switch it on
There is no account and no sign-in. Fault reports are off (faults.send: false) until you turn them on. The requests the program makes on its own, and what each carries, are listed in full on the privacy page; the update check and the fault report are described again below, with the files they touch.
One thing is done through your agent without a press, and it is on by default. While Claude Code waits for you and you are away, the bar types a one-word side question (/btw) into it every fifty minutes, for up to five hours after you last typed, so that its prompt cache does not cool. The request is Claude Code's own, on your account, and it costs a tenth of the input price for the conversation. It is on your screen, on the cache chip ("warm-up at 16:10"), and in the log as [warm]. Settings, Agents, Prompt cache turns it off (cache.keepWarm: false).
Claude Code
When Claude Code is installed, vobuda writes into ~/.claude/settings.json. Each hook is a command that calls vobuda's own command line, and every entry is ours by its whole path: a hook you wrote, even one that calls vobuda signal by hand, is left where it is.
| Hook | What vobuda does with it | Switch |
|---|---|---|
Stop | Marks the tab done | - |
Notification | Marks the tab waiting | - |
UserPromptSubmit | Clears the mark. Takes a snapshot of the project folder before the turn, and stops a key pasted into the request, with the reason | snapshots.enabled, fence.secrets |
StopFailure | Marks the tab failed, with the error | - |
PreCompact, PostCompact, SubagentStart, SubagentStop, CwdChanged | Notes beside the agent's numbers | - |
PostToolUse for Edit, Write, MultiEdit, NotebookEdit | The files panel reads again | - |
SessionStart | The window's brief for the agent | - |
PreToolUse on the shell and the writing tools | The guard: the last tool written down for the question in words; a write or delete outside the project refused; every delete refused; a key into a file that ships refused | fence.enabled, fence.neverDelete, fence.secrets |
The status line is set to vobuda's statusline.sh, which saves Claude Code's JSON beside the settings for the numbers line and then runs the status line you had before, printing what it printed. A status line of your own that happens to be called statusline.sh is told apart by its path and chained, not replaced. Removing vobuda's links (Settings, Agents, the link's switch) takes every one of these back out, puts your status line back, and leaves the rest of the file as it was.
Codex
Two things, and a way to tell them from yours.
The notify command
In ~/.codex/config.toml, notify is set to vobuda's notify.sh, which signals the window and then runs the notify you had before. Removal puts it back. A notify of yours is ours only when it names our script's whole path.
The brief
What the window can show and how to ask goes into ~/.codex/AGENTS.md between two comment marks of ours. Only that span is ever rewritten or removed.
Your shell
For prompt marks, meaning jumping between prompts and the exit code on the margin, vobuda hands each interactive shell its integration by the one road the shell has. zsh gets it through ZDOTDIR (your own ZDOTDIR is put back before any of your files is read), bash through an inherited PROMPT_COMMAND that removes its own line and keeps your profile's, fish through a vendor_conf.d folder on XDG_DATA_DIRS. The scripts are in ~/.config/vobuda/shell/, and nothing in your home folder is edited. shell.integration: false leaves the shell untouched.
Shells are owned by a keeper, the same executable started with --keeper in its own process group, so they outlive the window. The keepers listen on sockets in ~/.config/vobuda/pty/, and closing a block ends its shell and its keeper. shell.keep: false makes shells children of the window again. When the window starts, keepers that still answer bring their blocks back whatever the session setting says, and a keeper whose block is not in the window is ended rather than left running unseen.
What it reads
Your SSH config
~/.ssh/config, for the host names offered as blocks.
The agents' folders
~/.claude/ and ~/.codex/, for the agents' sessions, skills, models and settings shown on the bar.
The project of each block
Its git status for the files panel's marks, and a file's two sides for the changes block.
A copy of the project
git worktree makes the copy, beside the project's top folder.
Fault reports, off unless you say
The program records its own faults (a panic, a panel that threw, a promise that failed, a command that failed) in faults.json beside the settings. Each is scrubbed before it is written: your home folder's path becomes ~, the text is cut at a fixed length, and the screen shows you exactly what would leave. Nothing is sent until faults.send is true.
When it is, once a day the day's records go to https://faults.vobuda.com, a worker that files one issue per fingerprint in the public repository. A record carries the minute it happened, its kind, the module, a fingerprint, the scrubbed message, the frames where there were any, and a random machine id that is not tied to you. Never file contents, commands typed, environment variables or keys.
Updates
Once a day, and on Check for updates, the program asks https://vobuda.com/latest.json (and, when that fails, the same file on GitHub) for the newest version number, and https://registry.npmjs.org for the agents' newest versions. The request carries nothing about you.
Nothing is installed by itself. Updating an agent types its command into a block, where you can read it. Updating vobuda types the install line, which downloads the signed package, checks its checksum against the value in the script, checks Apple's signature, and installs it where vobuda already is.
What is kept beside the settings
state.json (what the window shows, for scripts), events.jsonl (what changed, trimmed past two megabytes), status/ (the agents' own numbers by pid), notes/, asks/, inbox/ (commands in flight), log.txt, faults.json, history.json, snapshots/ (the project before an agent's turn: refs in the project's own git, copies here for folders without git), pty/ (the keepers' sockets), awake.json (the holds that keep the Mac up, taken back after a restart), shell/ (the integration scripts) and bin/ (the command line and the status-line script).
A settings backup (vobuda backup) takes the settings and leaves the rest. The command line those hooks call is described on its own page.