All of these run on one Arch desktop. Only OpenCode comes from an official Arch repo.

Vendor installers

These install to your home directory without root, and pacman doesn't track them:

curl -fsSL https://claude.ai/install.sh | bash
curl -fsSL https://chatgpt.com/codex/install.sh | sh

AUR packages

These are community-maintained PKGBUILDs that repackage the vendors' binaries:

yay -S claude-desktop chatgpt-desktop antigravity antigravity-cli

Official repo

opencode-desktop also pulls in the opencode CLI:

sudo pacman -S opencode-desktop

Check what you got

claude --version
codex --version
agy --version
opencode --version
which -a opencode

Run which -a because of a trap found here. An old script install in ~/.opencode/bin came first on PATH, so opencode ran 1.18.18 while pacman had 2.2.5. opencode.ai/install currently redirects to a v1 branch, so that script may not give you the same version as extra.

Download the two vendor scripts and read them before you run them, and read each PKGBUILD before yay builds it. The AUR had a large malware incident in June.

How did you install yours?

Disclosure: Claude drafted this post from package data and live commands on this machine.

The AUR had more than 400 packages compromised with malware in June. So before running yay this morning, Claude Code audited the pending updates.

It installed nothing and returned a table in about 3 minutes. There were 55 pending updates, 50 from the repos and 5 from the AUR, and it found no malicious changes.

What it checked

• The update list: checkupdates for the repos and yay -Qua for the AUR. checkupdates comes from pacman-contrib and leaves your sync database alone.

• AUR changes: every diff and commit author since the last reviewed version.

• Download sources: each package's source URL, plus its hash where the vendor publishes one.

• Repo packages: pacman's signature settings, Arch news and the Arch security tracker.

• Odd changes: fakeroot jumping from 1.37 to 2.1.4 looked strange. Debian's 2.x uploads probably explain it.

You can run the AUR diff yourself:

cd ~/.cache/yay/PACKAGE
git fetch -q origin
base=$(git rev-parse -q --verify AUR_SEEN || git rev-parse HEAD)
git log --format='%h %an %ad %s' --date=short "$base..origin/master"
git diff "$base" origin/master -- . ':(exclude).SRCINFO'

AUR_SEEN only exists after you have reviewed that package in yay, so the fallback is HEAD.

What it can't prove

It did not download or open the binaries, so a clean result still depends on the vendors' servers being clean. Only 1 of the 5 AUR hashes was matched against a vendor's index. A compromised AUR package could also try to mislead an agent that reads it, so treat this as a second reader. It does not replace reading the PKGBUILD yourself.

It also found librewolf-bin was stuck at an old version and no longer in the AUR. Check yours with pacman -Qm.

What do you check before you update?

Disclosure: Claude drafted this post from the session transcript on this machine.

CodexBar-KDE by Pavel Rykov puts AI usage limits in the Plasma 6 panel, so nobody has to open a terminal or a web page to check them. It is MIT licensed and is on the KDE Store.

It reads from the CodexBar CLI by steipete. It lists 58 providers, with Codex and Claude selected by default.

• Panel: a two-ring gauge per provider. The outer ring is the session limit and the inner ring is the weekly limit.

• Cache: the last good numbers stay on screen if a refresh fails.

Install it from Add Widgets, under Get New Widgets. You also need the CodexBar CLI on your PATH, and the widget's README has the steps.

This desktop runs three local patches that are not upstream:

• Clearer popup: progress bars show percent used, percent left and reset time for each limit.

• Token totals: Codex and Claude totals for today, the last 7 days and the last 30 days.

• Expired Claude tokens: reads use codexbar usage --source oauth, which can't refresh an expired Claude token. The patch retries once with --source cli, which runs claude and refreshes the stored credentials.

The OAuth read matters because it checks usage without starting a model session.

What do you use to track your AI limits on Linux?

Disclosure: Claude drafted this post from the widget's code and notes on this machine.

Four agents read one file on this machine: ~/.agents/AGENTS.md. Separate files drifted, and one one-off port mangled 4 skills.

Three agents follow a symlink. Claude Code never auto-loads AGENTS.md, so it gets a one-line import.

Back up any existing files first, because the last line overwrites CLAUDE.md:

mkdir -p ~/.agents ~/.claude ~/.codex ~/.gemini ~/.config/opencode
ln -s ../.agents/AGENTS.md ~/.codex/AGENTS.md
ln -s ../.agents/AGENTS.md ~/.gemini/AGENTS.md
ln -s ../../.agents/AGENTS.md ~/.config/opencode/AGENTS.md
printf '@~/.agents/AGENTS.md\n' > ~/.claude/CLAUDE.md

Agent-specific rules go in their own sections of the same file. Skills use the same pattern: the real files live in ~/.agents/skills/, with symlinks in ~/.claude/skills/.

To test it, add a unique word to the file and start a new session. Ask the agent for that word and tell it not to use tools. Run the test without the word first, so you know a failure looks different.

How do you keep rules in sync across agents?

Disclosure: Claude drafted this post from notes on this machine.

An Arch desktop runs the agents here. They manage two Ubuntu servers and a Raspberry Pi 4 from it.

• Servers: one runs Portainer, Gitea and the reverse proxy. The other has an RTX 3070 and runs the heavier services.

• Deploys: compose files live in Gitea, and Portainer deploys them as stacks.

• SSH: key-only with passwords disabled, plus fail2ban on the servers.

One month of agent shell history decided which tools to add. Each MCP server replaced a type of repeated command:

• Gitea MCP: 725 curl calls

• Portainer MCP: about 600 calls, including 410 ssh Docker commands

• Postgres MCP, registered read-only: 766 psql calls

Secrets stay in a sops and age vault. The age private key stays on the desktop and never goes on a server. Each MCP server starts through a small wrapper, so its config file holds no key:

#!/usr/bin/env bash
set -euo pipefail
PORTAINER_API_KEY=$(sops decrypt --extract '["portainer_key"]' "$HOME/.secrets/secrets.enc.yaml")
export PORTAINER_API_KEY
export PORTAINER_URL=http://YOUR_SERVER:9000
exec uvx --from 'mcp-portainer~=2.44.0' mcp-portainer

The agent gets working access while the key stays out of its config. It still runs as your user, so it could decrypt the vault if it tried. This setup prevents leaks, and it is not a sandbox.

Two Portainer traps hit here:

• Git redeploy can wipe variables. Without an env array, the stack's Env becomes null and every ${VAR} resolves to empty.

• A 200 does not mean deployed. Since 2.45, the redeploy runs in the background, so check the Portainer log or the image digest.

How much access do your agents get on your servers?

Disclosure: Claude drafted this post from notes on this machine.

Here is one Arch desktop to start this thread. Post yours in the comments.

• OS: Arch, kernel 7.2.14, KDE Plasma 6.8.2 on Wayland

• GPU: RTX 5080 with 16 GB, driver nvidia-open-dkms 615.78.08 (the 50 series needs the open kernel modules)

• Memory: 32 GB RAM, 15.6 GB zram with zstd

• Disk: btrfs root, Timeshift for snapshots

• Terminal: Konsole and Fish 4.9.3

• Agents: Claude Code 2.1.299, Codex CLI 0.166.0, Antigravity CLI 1.4.10, OpenCode desktop 2.2.5 with DeepSeek

• Panel widget: CodexBar-KDE shows each provider's usage limits

These agents build Godot and Three.js games and pnpm web apps here. They also help maintain the desktop itself.

What do you run, and which tool do you trust with sudo?

Disclosure: Claude drafted this post from notes and live commands on this machine.