← graph

fix-tui-pi-chat-ipc-timeout

Fix TUI Pi chat false timeout and bare-model launch

Metadata

Statusdone
Assignedagent-935
Modelpi:openai-codex:gpt-5.6-sol
Created2026-07-29T22:11:05.984287526+00:00
Started2026-07-29T22:11:13.793027603+00:00
Completed2026-07-30T00:19:22.478948380+00:00
Tagstui, chat, pi, ipc, regression
Tokens71675695 in / 88585 out

Description

External production report from a Lustre-backed HPC graph using WorksGood 0.1.0+b27e34a831e3 and a valid Pi profile (worker/chat pi:openai-codex:gpt-5.6-sol high; agency/eval pi:openai-codex:gpt-5.6-luna low): TUI New chat displayed Error: Service IPC response timed out after 2s; the daemon is alive but unresponsive, while .chat-1 was already visible as in-progress turn 0 and the daemon logged Coordinator-1: persistent TUI tmux pane is live. Immediately afterward the daemon logged Error handling connection: Broken pipe (os error 32). Concurrent coordinator ticks repeatedly attempted a historical route-less .flip-implement-true-resilient, producing WG-EXEC-AGENCY-ROUTE-UNSELECTED, and some ticks exceeded the client timeout. This proves a post-commit response-loss/IPC-starvation failure, not an invalid Pi model definition: chat creation and the vendor pane succeeded, the client timed out, then the daemon replied to a closed socket.

Reproduce credential-free with a fake Pi and deterministic fault injection or coordinator delay exceeding the current 2s IPC response budget. Exercise the real TUI New chat path (PTY where appropriate), service IPC path, graph mutation, persistent chat runtime/tmux ownership, and response-loss boundary. Fix the architecture rather than merely inflating a timeout. A slow coordinator/eval/registry/graph tick must not starve chat IPC. A chat-create operation must have idempotent/reconcilable identity: if the task/runtime committed before the response was lost, the TUI must discover/select that exact chat and must not report a false creation failure or create a duplicate on retry. If mutation did not commit, it may fail clearly with no chat/runtime residue. Late replies to disconnected clients should be handled as expected cancellation evidence rather than noisy corruption. Existing live tmux ownership must never trigger a competing handler.

Also fix the attended-Pi UX boundary implicated by the report. TUI New chat must offer/use an attended bare-Pi launch when the user did not explicitly pin a per-chat model: invoke Pi without a --model override so Pi owns login and model choice (including its own model picker), while retaining the repo profile only as the unattended worker/agency service contract. Do not weaken fail-closed explicit routes/reasoning for unattended workers, evaluation, FLIP, or service startup. An explicit per-chat pi:<provider>:<model> must remain exact and continue to work. Persist/observe the actual chat session model when Pi reports it, without silently rewriting project worker/agency routes.

Regression requirements: simulate service work longer than 2s; assert New chat succeeds/reconciles exactly one .chat-N; assert it becomes selectable/attachable; assert no duplicate task, tmux pane, handler, or session is created; assert a late response/BrokenPipe cannot turn success into UI failure; assert bare attended Pi argv omits model while explicit per-chat model argv includes the exact provider/model; assert stale route-less eval work cannot block chat IPC; assert service restart preserves the chat and does not spawn beside a live tmux owner. Preserve failure evidence and use isolated HOME/WG graph with no credentials. Inspect existing chat IPC, TUI new-chat, terminal-host, and docs/bugs/tui-pi-chat-launch-enoent.md regressions before changing behavior.

Validation

  • Run the new real TUI/service/fake-Pi smoke at least three consecutive times.
  • Run existing TUI Pi chat launch/ENOENT, chat create, persistent tmux ownership, service IPC, and restart smokes identified from the manifest.
  • Run focused Rust tests for every touched module.
  • Run cargo fmt, cargo fmt --check, cargo clippy, and cargo test for affected crates/modules.
  • Validate both inherited bare-Pi chat and explicit per-chat Pi model cases from a freshly built candidate binary, never a stale PATH installation.
  • Do not claim completion until the candidate is merged and the accepted binary is installed.

Depends on

Required by

✓ Messages 6 messages (replied)

  1. #1user2026-07-29T22:13:40.107326727+00:00read
    Additional production regressions from the same live TUI session: (1) Pi did open and its persistent pane is live, but the user cannot type into it from the WG TUI — keyboard focus/input forwarding is broken. (2) Ctrl+O no longer exposes any information about available command keys/help as it previously did (it may be swallowed by the embedded Pi pane, wrong focus mode, or a keymap/help-overlay regression). Expand the exact PTY regression to attach/select the created Pi chat, send typed input through the real WG TUI, and prove the fake Pi receives exact bytes while command-mode/global escape remains reachable. Pin Ctrl+O’s intended behavior from current docs/history/source before changing it, then assert the discoverability/help surface remains accessible in both chat-focused and command modes. Do not accept task-created/pane-live as success unless interactive input works. Keep this within the current critical candidate if coherent; message back immediately if it reveals a separable root requiring a dependent task.
  2. #2fix-tui-pi-chat-ipc-timeout2026-07-29T23:51:44.649597556+00:00read
    Confirmed coherent same-root extension: persistent tmux creation inherited the outer/custom tmux server, while the embedded attach correctly unset TMUX but then fell back to the default server, so the attach client exited and WG lost its input-forwarding pane although the inner session stayed live. I’m fixing attach to preserve the exact outer socket explicitly while unsetting TMUX, and expanding the current real-TUI/Fake-Pi smoke for exact typed bytes plus Ctrl+O command/help discoverability in PTY and command modes; no dependent task needed.
  3. #3user2026-07-30T21:28:21.847107648+00:00sent
    Additional same-session report: once Pi chat is open, the assistant says its “contract” does not allow it to read repository files the user explicitly asks it to inspect. Investigate the exact attended-chat prompt, scope, cwd, Pi tool availability, and plugin/system instructions. An attended repository chat should have user-directed read access (subject to real OS/policy boundaries) and must not falsely claim a blanket no-read contract. Add a fake/real Pi prompt/tool regression: ask the selected chat to read a known repository file and prove the read tool is available and receives the repository-relative path, while writes remain governed by the intended chat scope. Do not solve by granting unattended evaluator/FLIP permissions or weakening their read-only containment. If this is a separable prompt/scope root, create a dependent task and report the exact contract text/source.
  4. #4user2026-07-30T21:28:35.480082279+00:00sent
    Product authority clarification from the reporter: the attended chat is the human’s interactive operator and should carry out whatever the human explicitly asks using Pi’s normal tools plus WG tools, subject only to real OS/project policy and explicit confirmation for irreversible/external side effects. It must not inherit bounded-evaluator, deep-FLIP, worker completion, `--no-tools`, `bare`, or blanket read-only constraints. If a real scope denies an operation, report the exact scope/tool/policy; never fabricate “my contract does not allow reading files.” Audit argv and all first-turn/system/addendum prompts for role leakage. Add assertions that chat can read, edit, and run a harmless command when user-directed, while evaluator containment remains unchanged.
  5. #5user2026-07-30T21:29:08.869904592+00:00sent
    Root cause confirmed in src/text/agent_guide.md lines 13-98 and repeated full contract: it explicitly says chat agents NEVER read/search/edit/run tests and ONLY read WG state. This is now an explicit product-policy change, not merely tool wiring. Replace the thin-task-creator prohibition for attended chats with a human-directed operator contract: read/search/edit/run/test/dispatch when explicitly requested; delegation is available, not mandatory. Retain confirmation for irreversible/external side effects and actual OS/project/tool scope. Update every duplicate/addendum/generated prompt and tests that assert the old STOP/NEVER behavior across Pi/Codex/Claude, while preserving worker and evaluator contracts unchanged. Add a prompt snapshot/regression proving the old prohibitions are absent only for attended chat and a behavioral fake-Pi test proving user-requested repository read succeeds.
  6. #6user2026-07-30T21:30:50.553113271+00:00sent
    Scope correction: do NOT implement the universal attended-chat authority policy in this task. Keep fix-tui-pi-chat-ipc-timeout focused on service IPC post-commit reconciliation, duplicate prevention, bare-vs-explicit Pi argv, pane attach/input forwarding, and Ctrl+O/help reachability. You may identify/report prompt leakage and ensure transport exposes normal Pi tools, but do not rewrite src/text/agent_guide.md or cross-handler role contracts; a separate dependent task owns that policy and behavioral prompt migration.

Log