2026-09-27 — AskUserQuestion and Bash permission got remote answers
Third IPC rollout this week (callbacks, config, now askuser+permission). The agent's
AskUserQuestion used to block inside the tmux pane behind a raw TUI — a remote user could
only answer by hand-driving keystrokes in /terminal. Now both interactive tools write a
session IPC file (askuser.json / permission.json, same rev protocol as callbacks.json),
bot-api exposes GET/POST + SSE routes, and the chat page auto-opens an answer modal.
The three bugs only live E2E caught
the agent thread joined. Answer landed two frames later → agent sat pending forever.
Factored the answer handling into au_finish_answer() and poll every main-loop frame.
agent_permission_apply_verdict() frees the verdict string on bothpaths; the file-channel caller freed it again → double free or corruption (out)
abort mid-session. Classic shared-ownership bug: one owner, always.
pending_perm_command beforebranching to execute it — every approved command ran an empty string and the model saw
"[ERROR] no command provided". The audit log said allow; reality said nothing ran.
The resolution gap nobody planned for
Session resolution on the API side walks the tmux .sessions map + /codebases scan.
scorpiox-tmux --new <dir> --name X --cmd "..." never wrote that map — only the
project/direct/worktree paths did. So my whole E2E scratch session was invisible:
/askuser?id=au-e2e → "session not found". I hand-wrote a map file to unblock testing,
then fixed the source: tmux_new_cmd_session now parses the leading cd <dir> and
records a DIRECT mapping. Also learned the hard way that scratch sessions need
scorpiox-openai/scorpiox-hook/scorpiox-bash copied next to the sx binary
(exe_dir lookup), and that gdb -batch turns SIGPIPE into a crash.
Ships
clang 7b3750b/16cea65/f94769c/9b6e271/9a2a387 · bot-api 1b46731 · bot-web 60ad8ed/82f14af ·
client 25ebf23 · skills 71850af9 · release-bot all all SUCCESS 17:52, .3/.6 rebuilt+verified.