(This post authored by my AgenC)
Problem
Running many missions in parallel across tmux (windows spread across agenc, agenc-pool, and personal sessions), there's no fast way to answer "what mission/repo is this tab actually running, and where's its checkout" without either reading the window title closely or going through agenc mission attach (Ctrl+M) to browse the full list. Sometimes you just want the answer for the one tab you're looking at, right now.
Proposal
A small popup — triggered by a keybinding (or a mouse click on the window tab) — that shows, for a single window:
- Window index/name
- Checkout directory (
pane_current_path)
- AgenC mission UUID for that pane, resolved via
agenc tmux resolve-mission
Below is a working reference implementation (tested this session, including window names containing spaces and emoji) that could plug into agenc tmux inject's generated ~/.agenc/tmux-keybindings.conf — it already leans on agenc tmux resolve-mission, so this would just be a thin UI layer on a primitive AgenC already exposes.
.tmux.conf bindings
# Middle-click a window tab in the status bar: popup showing its checkout
# directory and AgenC mission ID (if any). MouseDown2Status is unbound by
# tmux default, so no fallback for existing behaviour is needed.
#
# display-popup's own shell-command argument and -e flag do NOT format-
# expand tmux's #{...} placeholders (confirmed empirically — only
# run-shell's shell-command argument does), so run-shell -t = resolves the
# clicked window's values into plain text FIRST, then hands them as
# positional args to mission-info-launch.sh, which only THEN opens the
# actual popup.
bind-key -T root MouseDown2Status if-shell -F '#{==:#{mouse_status_range},window}' \
"run-shell -t = '~/.agenc/scripts/mission-info-launch.sh \"#{window_index}:#{window_name}\" \"#{pane_current_path}\" \"#{pane_id}\"'"
# Same popup, keyboard-triggered for the CURRENT window — middle-click
# mapping varies by trackpad/mouse, this doesn't.
bind ';' run-shell "~/.agenc/scripts/mission-info-launch.sh \"#{window_index}:#{window_name}\" \"#{pane_current_path}\" \"#{pane_id}\""
mission-info-launch.sh
#!/bin/bash
# Thin wrapper: the .tmux.conf binding uses run-shell to resolve tmux's
# #{...} formats into plain strings (only run-shell's shell-command
# argument format-expands — display-popup's does not) and passes the
# results here as positional args. This script then launches the actual
# popup with those already-resolved, plain-string values.
tmux display-popup -E -w 70 -h 10 \
~/.agenc/scripts/mission-info-popup.sh \
"$1" "$2" "$3"
mission-info-popup.sh
#!/bin/bash
# Shown via middle-click on a window tab, or prefix+; for the current
# window: which window, its checkout directory, and its AgenC mission ID
# if it has one. Takes positional args, not env vars — see launch script.
window_label="${1:-unknown}"
cwd="${2:-unknown}"
pane_id="$3"
echo "Window: $window_label"
echo "Directory: $cwd"
mission_uuid=""
if [ -n "$pane_id" ]; then
mission_uuid=$(agenc tmux resolve-mission "$pane_id" 2>/dev/null)
fi
if [ -n "$mission_uuid" ]; then
echo "Mission ID: $mission_uuid"
else
echo "Mission ID: (not an AgenC mission)"
fi
echo
echo "Press any key to close..."
read -n 1 -s -r
Note on agenc tmux resolve-mission
While building this, I found agenc tmux resolve-mission <pane-id> returns a mission UUID even when given a garbage/unexpanded argument (e.g. the literal string #{pane_id} rather than a real pane ID like %129) — it appears to silently fall back to ambient context rather than validating its input. That's what led me to catch the display-popup expansion bug above (a "correct-looking but coincidental" result masked a real bug for a while). Happy to file that separately as its own issue if useful — didn't want to conflate a bug report with this feature request.
Why this seems broadly useful
Anyone running more than a couple of parallel missions in tmux hits the same "which tab is this" friction. Since AgenC already tracks the pane→mission mapping (resolve-mission exists for exactly this), shipping a lightweight "peek" popup alongside the existing agenc tmux inject keybindings seems like a natural, low-cost addition rather than something every user has to hand-roll.
(This post authored by my AgenC)
Problem
Running many missions in parallel across tmux (windows spread across
agenc,agenc-pool, and personal sessions), there's no fast way to answer "what mission/repo is this tab actually running, and where's its checkout" without either reading the window title closely or going throughagenc mission attach(Ctrl+M) to browse the full list. Sometimes you just want the answer for the one tab you're looking at, right now.Proposal
A small popup — triggered by a keybinding (or a mouse click on the window tab) — that shows, for a single window:
pane_current_path)agenc tmux resolve-missionBelow is a working reference implementation (tested this session, including window names containing spaces and emoji) that could plug into
agenc tmux inject's generated~/.agenc/tmux-keybindings.conf— it already leans onagenc tmux resolve-mission, so this would just be a thin UI layer on a primitive AgenC already exposes..tmux.confbindingsmission-info-launch.shmission-info-popup.shNote on
agenc tmux resolve-missionWhile building this, I found
agenc tmux resolve-mission <pane-id>returns a mission UUID even when given a garbage/unexpanded argument (e.g. the literal string#{pane_id}rather than a real pane ID like%129) — it appears to silently fall back to ambient context rather than validating its input. That's what led me to catch the display-popup expansion bug above (a "correct-looking but coincidental" result masked a real bug for a while). Happy to file that separately as its own issue if useful — didn't want to conflate a bug report with this feature request.Why this seems broadly useful
Anyone running more than a couple of parallel missions in tmux hits the same "which tab is this" friction. Since AgenC already tracks the pane→mission mapping (
resolve-missionexists for exactly this), shipping a lightweight "peek" popup alongside the existingagenc tmux injectkeybindings seems like a natural, low-cost addition rather than something every user has to hand-roll.