pi-intercom over SSH: the 30-second guide

pi-intercom is same-machine only — it talks via a Unix socket at ~/.pi/agent/intercom/broker.sock. sshfs won't forward it (sockets aren't regular files). Forward the socket itself.

1. Keep the broker alive on host A

pi
ls -l ~/.pi/agent/intercom/broker.sock # must exist

2. Forward it to host B — don't use ~ after :

rm -f ~/.pi/agent/intercom/broker.sock
REMOTE=$(ssh user@hostA 'echo $HOME/.pi/agent/intercom/broker.sock')
ssh -nNT -o StreamLocalBindUnlink=yes -L $HOME/.pi/agent/intercom/broker.sock:$REMOTE user@hostA

3. Use it

pi
intercom list # shows sessions from both hosts


Troubleshooting channel 1: open failed: remote socket missing (broker died after 5s idle), ssh -v, or AllowStreamLocalForwarding no on hostA (sudo sshd -T | grep allowstreamlocalforwarding).

gentoo: Fixing Flameshot's Wrong-Monitor Bug on XFCE

If Flameshot's screenshot selector on Linux keeps popping up on the wrong monitor — even one that's turned off — check your primary display setting before anything else.

On my Gentoo + XFCE4 + X11 setup, Flameshot (Flatpak) kept opening its capture overlay on my second monitor, no matter what I did. Compositor tweaks, permissions, config resets — nothing worked.

The actual cause: my main monitor wasn't set as primary in XFCE's display settings. Flameshot just follows whatever XRandR reports as primary, regardless of which screen is actually active.

One change in Settings → Display, and it's been working perfectly since.

xpra: insufficient permissions to use socket path '/var/run/xpra/tux-5'

On the remote host, you have to be added to xpra group, e.g:

sudo gpasswd -a user_name xpra

Reasonix: use openrouter as provider for DeepSeek

In ~/.reasonix/config.toml:

[[providers]]
name = "deepseek-flash"
kind = "openai"
base_url = "https://openrouter.ai/api/v1"
model = "deepseek/deepseek-v4-flash"
api_key_env = "OPENROUTER_API_KEY"
context_window = 1000000
price = { cache_hit = 0.0028, input = 0.14, output = 0.28, currency = "$" }
And in ~/.reasonix/.env:

OPENROUTER_API_KEY=sk-or-v1-xxxx

xpra: USE flags to install on gentoo without using nvidia

/etc/portage/package.use/xpra should be:

x11-wm/xpra -video_cards_nvidia
x11-base/xorg-server xvfb

open terminal in docker

docker run --rm --network=host -v open-terminal:/home/user -e OPEN_TERMINAL_API_KEY=your-secret-key --name open-terminal ghcr.io/open-webui/open-terminal run --host 0.0.0.0 --port 8001

open-webui: Account Activation Pending

If you get the following error: Account Activation Pending
Contact Admin for WebUI Access
Your account status is currently pending activation.
To access the WebUI, please reach out to the administrator.
Admins can manage user statuses from the Admin Panel.
Admin: User (admin@localhost)
Open WebUI stores each account's role (pending, user, admin) in its SQLite database, and normally the very first account created is auto-promoted to admin — but if that didn't happen cleanly (e.g. a previous run, crash, or port conflict interfered), your account gets stuck as pending, which blocks access even with WEBUI_AUTH=False. The fix is to update that account's role directly in the database and then just refresh the browser tab.

docker exec -it open-webui python3 -c "
import sqlite3
conn = sqlite3.connect('/app/backend/data/webui.db')
c = conn.cursor()
c.execute(\"UPDATE user SET role='admin'\")
conn.commit()
print(c.rowcount, 'user(s) updated')
"

horizon-client: invalid locale and no font don't work well with xfce4 black theme

env GTK_THEME=Adwaita LANG=en_US.UTF-8 LC_ALL=en_US.UTF-8 horizon-client

flameshot error: Screenshot portal timed out after 30 seconds

On a linux (arch or gentoo) with xfce4 and X server, flameshot does not run and gives an error:
flameshot: error: Screenshot portal timed out after 30 seconds
flameshot: error: Unable to capture screen

To fix that:
mkdir -p ~/.config/flameshot
Create or open if exists, ~/.config/flameshot/flameshot.ini, and add to it
[General]
useX11LegacyScreenshot=true
Restart flameshot

Gentoo and nvidia: open /dev/dri/card0: No such file or directory

Gentoo upgrade broke Xorg? It's probably your NVIDIA module.

After a Gentoo system upgrade that includes a new kernel, Xorg can fail to start with a cryptic error: "open /dev/dri/card0: No such file or directory". The display manager dies, XFCE never loads, and you're left staring at a TTY.

The cause is simple. The upgrade installed new kernel sources, but the /usr/src/linux symlink was left pointing at the old ones — or pointing nowhere useful. When nvidia-drivers tries to rebuild its kernel module against the new kernel, it can't find the sources and silently fails. No module, no /dev/dri/card0, no Xorg.

To fix it, first check which kernel you're running and which sources are available:
uname -r eselect kernel list
Then point the symlink at the matching sources: eselect kernel set 1
Finally, rebuild the NVIDIA kernel module: emerge @module-rebuild
Restart your display manager and everything should be back to normal. The lesson: after any Gentoo kernel upgrade, always verify your /usr/src/linux symlink and run emerge @module-rebuild before rebooting.