Scribbles for my memory

Git Bash doesn't ship tmux. A standalone MSYS2 install does — but out of the box it ignores your Windows $HOME, doesn't inherit the Windows PATH, and if you wire it into Windows Terminal, silently ignores the config you think is fixing it.

Two settings make MSYS2 match Git Bash:

HOME — edit C:\msys64\etc\nsswitch.conf:

db_home: env windows cygwin desc
db_shell: env windows cygwin desc
db_gecos: env windows cygwin desc

Default MSYS2 uses cygwin desc, which invents a separate /home/<user> instead of your real Windows profile. This is the exact line Git for Windows ships with, so it makes MSYS2 pick up C:\Users\<you> — same .bashrc, .gitconfig, .ssh as Git Bash, no copying needed.

PATH — MSYS2 doesn't inherit the Windows PATH by default, so anything installed via scoop/chocolatey/etc. won't resolve. Set MSYS2_PATH_TYPE=inherit in the relevant launcher .ini (mingw64.ini, ucrt64.ini, next to the exe in C:\msys64).

The gotcha: if you launch MSYS2 through Windows Terminal with the commonly documented

msys2_shell.cmd -defterm -here -no-start -ucrt64

the .ini file is never read. Only the GUI launchers (mingw64.exe, ucrt64.exe) read it — msys2_shell.cmd has its own separate flag:

msys2_shell.cmd -defterm -here -no-start -ucrt64 -use-full-path

Add -use-full-path straight to the Windows Terminal profile's commandline. Or, for a fix that works no matter how MSYS2 gets launched (Windows Terminal, VS Code, a script), set it once at the system level from an elevated shell:

[Environment]::SetEnvironmentVariable('MSYS2_PATH_TYPE', 'inherit', 'Machine')

Restart the terminal for it to take effect. Then pacman -S tmux, and you've got tmux running in an environment that otherwise looks and feels exactly like Git Bash.

When an AI harness calls an external agent, the visible action is often just one command. The real problem starts immediately afterward: the caller may finish its turn, the tool runner may disappear, the worker may need to outlive its parent, and the reply still has to reach the right session. Pipes and background processes handle the happy path; they do not define a reliable lifecycle.

Baton is a local coordination layer for that boundary. It gives an external-agent call a mailbox and a durable message flow. A request enters an inbox, baton serve claims it, launches the configured agent, and writes the response to an outbox. Its mailbox uses atomic state transitions, single-instance locking, stale-work reclaim, and cooperative stop. Delegation becomes an explicit, inspectable protocol instead of an accidental child-process relationship.

orchestrator / harness → Baton inbox → baton serve → external agent
orchestrator / harness ← Baton outbox ← baton serve ← external agent

That is why Baton is the harness of the harness. The outer harness manages the current model turn, tools, and user interaction. Baton manages the boundary where that harness asks another agent or worker to do something. It does not replace the external model and it does not need to understand the model's reasoning. It provides the durable submission, delivery, retry, and recovery behavior that the outer harness should not have to reinvent for every provider.

The foundation is already useful, but the larger design is a service, not a collection of detached commands. A host-owned Baton supervisor can spawn each session's baton serve, persist its identity and state, and stop or reap it deliberately. That is materially stronger than setsid or disown: detachment changes a process's parent; supervision gives the process a real owner that survives the submitting client.

This is where the companion bg-run layer fits. bg-run is the agent-facing convenience: start long work and end the current turn. Baton can provide the generic task lifecycle underneath it—stable task IDs, isolated process groups, durable results, and immutable milestone or terminal events delivered back to the role mailbox. The agent receives a wake-up when there is something to consume instead of sleeping and polling.

The names should stay in their layers. bg-run describes a useful action in my-ai-team; Baton should expose provider-neutral primitives such as task or job. A future supervisor can then own both session servers and asynchronous tasks without knowing whether the caller was Codex, another harness, or a human-operated CLI.

The opportunity is bigger than a better way to launch subprocesses. If an AI harness is the harness for one agent, Baton can become the infrastructure for a whole population of delegated workers: routing their messages, preserving their work, waking their consumers, and eventually supervising their lifecycles. That is why Baton deserves to be designed as a foundation, not as a thin wrapper around tmux.

bg-run sounds like a small shell convenience: start a command and let the agent continue. Its real contract is much larger. The command must survive the end of the current agent turn, record its result, report meaningful milestones, and wake the right session later. That is a lifecycle and delivery problem, not an ampersand problem.

A reliable implementation needs a durable owner, an isolated process group, cancellation and reaping, durable result and event records, and a callback path into the session that started the work. It also needs at-least-once delivery, because a wake-up can be retried without creating a second task.

The tmux implementation works because tmux happens to provide most of this machinery. A helper session owns the process after the caller returns, and a pane gives the result a place to wake. bg-run can write immutable milestone and final events, then the agent can consume them on its next turn. On a tmux host, this is a perfectly useful adapter.

But tmux is a hosting-specific workaround, not the underlying abstraction. A Baton driver has no pane and no TMAT_PANE, so the tmux implementation correctly refuses to run. Replacing it with setsid, disown, or another backgrounding trick would not fix the ownership problem: an external tool runner can still clean up the caller's descendant process tree, leaving a state file that names a dead worker. Detaching a process is not the same as giving it a supervisor.

Baton already has the right foundation. baton serve is a resident mailbox responder with atomic pending/claimed/done delivery, single-instance locking, stale-work reclaim, and cooperative stop. The missing piece is making that residency real for the whole integration: a host-owned baton service process, run in the foreground under something like a systemd user service, should spawn and own each session's baton serve and each asynchronous task. The client that submits work must not be its owner.

On top of that service, a generic baton task start API can return a stable task ID immediately, persist the command specification and state, run the task in its own process group, capture its output, and emit immutable milestone and terminal events to the requested Baton mailbox. task status and task cancel complete the lifecycle; session teardown cancels and reaps its tasks. The agent starts the task, ends its turn, and is woken by the mailbox when there is something worth reading. No sleep 50, PID loop, or result-file polling is needed.

That is why the Baton design is the general solution: it treats ownership and notification as a protocol rather than an accidental property of a terminal multiplexer. bg-run remains a good agent-facing name in my-ai-team because it describes the user action. Baton itself should expose a provider-neutral task or job primitive, with my-ai-team's bg-run as one adapter. Tmux can remain a useful adapter where it exists; Baton supplies the real owner where it does not.

After a reboot, every gh command returned HTTP 401: Requires authentication — even though you ran gh auth login ages ago. It looks like "the reboot wiped the auth."

The usual culprit: the token was saved in the system keyring (libsecret / gnome-keyring), and you log in over plain SSH (publickey). On an SSH login PAM never sees your password, so pam_gnome_keyring doesn't unlock the keyring — only a desktop/GUI login does that as a side effect. After a reboot the keyring stays locked, gh can't read the token, and you get a 401. It's not really about the reboot; it's that after the reboot no desktop login ever unlocked the keyring.

On a headless / SSH-only box, don't hand your credentials to the keyring. The simplest fix is an environment variable — gh reads it first and never touches the keyring or hosts.yml:

# ~/.bashrc.secret (sourced by login shells)
export GH_TOKEN=ghp_xxxxxxxxxxxxxxxxxxxx

Verify without printing the token — just check which account it resolves to:

gh api user -q .login      # prints your username on success

GH_TOKEN loads with every login shell, so reboots and pure SSH both stay stable. Clear the now-redundant credential in the keyring / hosts.yml (gh auth logout) to keep a single source of truth.

Broader lesson: on a headless machine, anything that assumes an interactive desktop session — keyring unlocking, a resident user-level systemd service — will bite you. Prefer session-independent mechanisms (environment variables, loginctl enable-linger).

机器重启后,gh 命令全线 HTTP 401: Requires authentication,可你明明早就 gh auth login 过。奇怪的是,好像"重启一下授权就没了"。

真凶多半是:token 存进了 系统 keyring(libsecret/gnome-keyring),而你走的是纯 SSH(publickey)登录。SSH 登录时 PAM 拿不到你的登录密码,pam_gnome_keyring 不会解锁 keyring——只有桌面/GUI 登录才会顺带解锁。于是重启后 keyring 一直锁着,gh 读不出 token,直接 401。这跟"重启"本身无关,是"重启后再没有任何桌面登录去解锁 keyring"。

无头/纯 SSH 机器上,别把凭据托付给 keyring。最省心的是用环境变量,gh 优先读它,完全不碰 keyring、也不落 hosts.yml:

# ~/.bashrc.secret (被登录 shell source)
export GH_TOKEN=ghp_xxxxxxxxxxxxxxxxxxxx

验证时别把 token 打出来,看它解析到哪个账号就行:

gh api user -q .login      # 打印用户名即成功

GH_TOKEN 随登录 shell 加载,重启、纯 SSH 都稳。清掉 keyring/hosts.yml 里那份冗余凭据(gh auth logout)可保持单一来源。

更广的教训:无头机器上,任何依赖"交互式桌面会话"的机制——keyring 解锁、user 级 systemd 服务常驻——都会踩坑,优先选不依赖会话的方案(环境变量、loginctl enable-linger)。