Persistent VM/hostname status indicator across agent harnesses #7

New issue

Closed

opened 2026-07-15 22:29:07 +01:00 by allod-agent · 0 comments

allod-agent commented

2026-07-15 22:29:07 +01:00

Member

User story: So that I can keep long-running agent sessions straight, each agent UI should show a persistent environment identity indicator sourced from configuration rather than relying on a one-time startup message.

Part of the "Environment identity & capability descriptor" arc.

When several agent sessions stay open for hours across multiple VMs, there is no at-a-glance way to tell which VM a given session is running on. A one-time message at session start does not help — after tabbing away to other tasks and scrolling, the operator needs a persistent, always-visible indicator. Add a persistent status indicator showing the VM's hostname in each agent harness's own UI, sourced from the host configuration so every VM shows its own identity.

Harness landscape (verified against the tools installed on allod-dev):

Pi (pi-coding-agent 0.80.3): supports a persistent footer status via the extension API (ctx.ui.setStatus(...) on session_start), auto-discovered from ~/.pi/agent/extensions/*.ts and loaded via jiti (TypeScript, no build step). Primary target.
Claude Code: supports a statusLine command in ~/.claude/settings.json that renders a persistent status line from a script's stdout.
Codex: no status-bar customization hook found in its CLI or config.toml; out of scope unless one is identified.

Implementation home is the allod/profiles home configuration, alongside the existing modules/ai-agents.nix that already generates the per-harness pointer files. Source the hostname from osConfig.networking.hostName so it is one fact fanned out per harness and applies to every dev VM that imports the module. Config-only; no secrets, provisioning, or private data (hostnames are public-safe).

A dev plan (allod/strategy/dev-plans/agent-vm-status-indicator.md) will pin the per-harness interface contracts, resolve ~/.claude/settings.json ownership (own vs. merge, to avoid clobbering operator settings), decide what the indicator shows beyond the hostname, and define acceptance tests that prove the indicator actually renders rather than merely that the config files are generated.

**User story:** So that I can keep long-running agent sessions straight, each agent UI should show a persistent environment identity indicator sourced from configuration rather than relying on a one-time startup message. _Part of the "Environment identity & capability descriptor" arc._ --- When several agent sessions stay open for hours across multiple VMs, there is no at-a-glance way to tell which VM a given session is running on. A one-time message at session start does not help — after tabbing away to other tasks and scrolling, the operator needs a persistent, always-visible indicator. Add a persistent status indicator showing the VM's hostname in each agent harness's own UI, sourced from the host configuration so every VM shows its own identity. Harness landscape (verified against the tools installed on allod-dev): - Pi (`pi-coding-agent` 0.80.3): supports a persistent footer status via the extension API (`ctx.ui.setStatus(...)` on `session_start`), auto-discovered from `~/.pi/agent/extensions/*.ts` and loaded via jiti (TypeScript, no build step). Primary target. - Claude Code: supports a `statusLine` command in `~/.claude/settings.json` that renders a persistent status line from a script's stdout. - Codex: no status-bar customization hook found in its CLI or `config.toml`; out of scope unless one is identified. Implementation home is the `allod/profiles` home configuration, alongside the existing `modules/ai-agents.nix` that already generates the per-harness pointer files. Source the hostname from `osConfig.networking.hostName` so it is one fact fanned out per harness and applies to every dev VM that imports the module. Config-only; no secrets, provisioning, or private data (hostnames are public-safe). A dev plan (`allod/strategy/dev-plans/agent-vm-status-indicator.md`) will pin the per-harness interface contracts, resolve `~/.claude/settings.json` ownership (own vs. merge, to avoid clobbering operator settings), decide what the indicator shows beyond the hostname, and define acceptance tests that prove the indicator actually renders rather than merely that the config files are generated.