Repository navigation
Description
What happened
Plain codeaf feels stalled before its first screen, and starting or opening a conversation can freeze the terminal UI. Audited dev@e7976208e and release build 14a7fdfac on 2026-09-28.
Observed first screen: 2.73 s on an initial launch, 0.90 s on a second launch. /new took approximately 0.9 s before started a fresh conversation behind home. A controlled two-second catalog response held launch assembly for the same two seconds. A controlled 250 ms conversation-opening callback blocked the UI caller for the full 250 ms.
Home typing sometimes feels frozen in the field, but the severe typing stall has not yet been reproduced. A profile with 62 conversations showed roughly 83–105 ms to display typed text in a coarse terminal probe.
Replication
Deterministic (no model).
- Run
make test-focus PKGS=./cmd/codeaf RUN='TestThe(SubharnessWiringAsksTheCatalogNothingThatWaits|LaunchesBlockingCatalogReadsDoNotGrow)$'. The tests pass while allowing eleven blocking catalog reads during launch. - In the same launch fixture, hold the catalog HTTP response behind a channel before calling
openV3Launch. Launch cannot finish until that channel is released. - Provide a held
Options.StartorOptions.Opencallback to the TUI fixture and invoke new/open through home. The callback is invoked on the update path, preventing drawing/input while held.
Field (real terminal).
Build with make build, then run bin/codeaf chat --model deepseek/deepseek-v4.1-flash --one-model with OpenRouter configured. Open home, type a draft, start a new conversation, and reopen an inactive conversation. No model request is needed to observe launch and blank /new; budget two minutes for manual interaction.
Where
v3Subharnesses,leafBuild.contextLength, and eagerv3RunHarnesstool bridge construction.openBeside,startBeside,renewRefusing, and their home callers.importForeignSkillsBeforeFirstMessage, called synchronously by everyopenV3Launch.homeView.buildWorld, which recalculates matching scores inside the sort comparator.homeBeat/furnishHome, whose remaining synchronous work requires profiling separately from cached hosted reads.
The fix
Draw and accept input independently of catalog discovery and conversation opening. Keep the draft and destination stable while opening; submit only after the intended conversation is ready. Avoid repeated search scoring and unnecessary initialization. Preserve skill availability before the first message and existing conversation ownership semantics.
Acceptance
- e2e: real terminal launch, home typing,
/new, and reopening remain usable; an OpenRouter turn usesdeepseek/deepseek-v4.1-flashfor every model role and reaches a completed answer in the intended conversation. - Regression: a held catalog request does not block launch assembly; held new/open callbacks do not block input or repaint and cannot send a draft to the previous conversation.
- Regression: refused/cancelled openings retain the draft, and delayed results cannot replace a newer conversation selection.
- Performance: record before/after timings, distinguishing actual improvement from unconfirmed typing-stall causes.
- Update the manual and changelog for the resulting behavior; do not claim unresolved paths are fixed.
Activity
santoshkumarradha commentedon Sep 28, 2026
The first fix is in #1662 (currently awaiting the final test gate).
Held-response regressions now prove that catalog discovery cannot hold launch assembly or agent creation, and that home new/open callbacks cannot hold drawing or input. Draft delivery, cancellation, refusal, and locked-conversation fallback are covered. Search ranking no longer recalculates each match inside sorting.
The real macOS probe distinguishes feedback from completion:
/newnow shows feedback in 109–111 ms while actual opening finishes in 817–872 ms. Previously the terminal gave no feedback until roughly 0.9 seconds. These are coarse observations including polling/command overhead, not latency percentiles.Keep this issue open after that PR: initial first-screen timing still varies (0.66–4.62 seconds across four runs), the severe typing freeze has not been reproduced, and skill-import/periodic-home-refresh costs still need isolation. The real-terminal home and conversation/search scenarios passed with OpenRouter
deepseek/deepseek-v4.1-flash, confirmed in the recorded usage model.AbirAbbas commentedon Oct 1, 2026
Shipped in stable v0.6.0: https://github.com/Agent-Field/CodeAF/releases/tag/v0.6.0
!shell line typed on home went to the model instead of the shell. A test covers it.Measured on the published linux-amd64 assets. The home had no saved model list, and a proxy held every request for 40 s, which is the stall this issue describes:
On the candidate build: with a day-old list, the first frame came at 0.17 s;
/newfeedback appeared at ~20 ms; and a message typed on home was sent once, to the intended conversation. Five tmux happy-path lanes passed on that binary. Their minor findings are #1727, #1728 and #1729, none of them in these paths.Leaving this open as Santosh asked. Still not isolated: first-screen variance across warm launches, the unreproduced typing freeze, and the skill-import and periodic home-refresh costs.
docs: changelog entries for the #1659 responsiveness fixes
docs: screen recordings of the #1659 transitions (before/after, home …
docs: #1659 enter-timing measurement evidence (Spark, raw runs)
The shared road's door leaves the update loop; every send rides the f…
The foreign-skill pass leaves the open; the first turn holds for it, …
chat: defer home's rescan while a conversation door is in flight
docs: changelog entries for the #1659 responsiveness fixes
docs: screen recordings of the #1659 transitions (before/after, home …
docs: #1659 enter-timing measurement evidence (Spark, raw runs)