Skip to content

Optimistic submitted user prompts are buried behind semantic/work rows #239

New issue
New issue
Closed
#252
Closed
Optimistic submitted user prompts are buried behind semantic/work rows#239
#252

Description

@Juliusolsson05
Juliusolsson05
opened on May 19, 2026

Problem

Two manual debug bundles show the same user-facing failure: after submitting a prompt, the prompt appears to be missing from the feed. The logs show the data is not actually lost. The optimistic user row is created and included in the render row model, but it is not at the bottom/latest end of the feed. Semantic-history rows and the transient work row (submitting / thinking / requesting / responding) come after it, so the visible latest area can make it look like the submitted user prompt never rendered.

This is distinct from prompt-submit failures. The submit path fired, optimistic_user_add fired, and the row exists. The problem is render ordering / latest-scroll ownership.

Evidence

Manual bundle 1:

  • bundle: ~/.config/agent-code/debug-bundles/2026-05-19T08-50-44-275-21e655e8
  • note: did not show the user prompt? (real issue not claude thing)
  • feed-debug.jsonl at 2026-05-19T08:50:38.339Z:
    • submit started with baseline
    • optimistic_user_add
    • uuid: optimistic-codex-user:1779180638339
    • text begins with: Well, we can create a new issue...
  • immediate render at 2026-05-19T08:50:38.347Z:
    • visible_rows changes 96 -> 98 (+2 -0)
    • the optimistic user row is present in the full row list
    • the last rows are semantic history rows plus work:submitting:none
  • subsequent renders keep the optimistic user row in the model, but the tail remains semantic/work rows (thinking, requesting, responding).

Manual bundle 2:

  • bundle: ~/.config/agent-code/debug-bundles/2026-05-19T09-03-10-738-21e655e8
  • note: same issue, no user propmt rendering?
  • feed-debug.jsonl at 2026-05-19T09:03:06.878Z:
    • optimistic_user_add
    • uuid: optimistic-codex-user:1779181386878
    • text begins with: That's great. So please now break down to me all the issues...
  • immediate render at 2026-05-19T09:03:06.886Z:
    • visible_rows changes 112 -> 114 (+2 -0)
    • the optimistic user row is present in the full row list
    • the last rows are semantic history rows plus work:submitting:none
  • captured state-snapshot.json and HTML contain the prompt text, confirming this is not a storage/transcript loss.

Likely cause

The feed row builder allows semantic-history/current-work rows to sit after transcript/optimistic user rows. When submit happens, the newly-added user row is not treated as the latest visual anchor. The latest/bottom area is then owned by provider semantic/work rows, so the UI looks like it skipped the user prompt.

Desired behavior

When a user submits a prompt:

  • the optimistic user row should be visible as the latest user-authored event immediately after submit
  • the feed should scroll/anchor to the submitted prompt or otherwise keep it in view before transient work rows take over
  • semantic history/work rows must not bury a freshly submitted user row in a way that makes the prompt appear absent

Acceptance criteria

  • Add a regression test or debug-render fixture where optimistic_user_add is followed by semantic/work rows, and assert the submitted prompt remains visible/anchored as the latest user action.
  • Fix row ordering and/or scroll anchoring so a freshly submitted prompt cannot be hidden behind semantic history/work rows.
  • Preserve the distinction between actual missing prompt data and prompt-present-but-buried rendering; debug logs should make that distinction easy to verify.

Related

Activity

  1. Juliusolsson05 commented on May 19, 2026

    @Juliusolsson05
    Juliusolsson05
    on May 19, 2026
    OwnerAuthor

    Verified against the captured HTML, not only feed-debug.jsonl row arrays.

    The user prompt rows are present in both html-clean.html and html-raw.html, but they are positioned earlier in DOM/text order, above later assistant/tool output. This matches the user report: while scrolling through the visible chat history, the user prompts can effectively disappear because they are not at the latest/bottom position where submitted prompts are expected.

    Bundle 2026-05-19T08-50-44-275-21e655e8:

    • html-clean.html contains data-entry-uuid="optimistic-codex-user:1779180638339"
    • prompt text Well, we can create a new issue... starts at HTML offset 39191
    • stripped text order places that prompt around char 4008
    • later assistant content like There are currently 28 open GitHub issues... appears much later around char 12814

    Bundle 2026-05-19T09-03-10-738-21e655e8:

    • html-clean.html contains data-entry-uuid="optimistic-codex-user:1779181386878"
    • prompt text That's great. So please now break down... starts at HTML offset 23139
    • stripped text order places that prompt around char 2735
    • later assistant/tool output appears after it, including There are currently 28 open GitHub issues... around char 7458 and Created the issue... around char 10228

    So the sharper bug statement is: submitted user prompts are present in the DOM, but they are ordered/anchored above subsequent assistant/tool rows instead of remaining visually adjacent to the turn they triggered or anchored as the latest user action. The acceptance criteria should verify DOM/order/scroll placement, not just row existence.

  2. Juliusolsson05 commented on May 19, 2026

    @Juliusolsson05
    Juliusolsson05
    on May 19, 2026
    OwnerAuthor

    Review-agent follow-up

    Four read-only review agents checked the rendering diagnoses. For this issue, both Claude/Codex agreed the visible symptom is correctly identified: the submitted prompt is not lost; it is present/rendered but can be visually buried.

    Sharper diagnosis:

    • The feed is structurally rendered in planes: committed/optimistic entries first, then semantic history/current turn, then work rows.
    • addOptimisticCodexUserEntry() appends the submitted Codex prompt as a normal entry-plane user row.
    • shouldQueueOptimisticCodexUserEntry() only queues when semantic.currentTurn is actively running.
    • It does not account for completed-but-still-rendered semantic.history, so the optimistic user row can land above prior-turn semantic history that is still visible while JSONL catches up.

    Important caveats from review:

    • This is more structural than the original issue wording implied. The row builder does not merely "allow" semantic/work rows after user rows; the feed's two-plane render order makes that ordering mandatory.
    • Scroll anchoring to the submitted prompt is likely not the right primary fix, because new assistant output streams below it and anchoring there could hide the live response.
    • A naive fix of "queue whenever semantic history is non-empty" is also risky because Codex semantic history can persist legitimately after committed rows. The fix needs either better plane ordering / special optimistic-submit placement, or a more precise way to identify unsettled semantic history that should keep the prompt out of the committed entry plane.

    Useful code references from review:

    • src/renderer/src/features/feed/ui/Feed.tsx renders entries before semantic history/current/work.
    • src/renderer/src/features/feed/model/renderModel.ts builds debug rows in the same order.
    • src/renderer/src/workspace/hook/actions/streaming.ts creates optimistic Codex user entries and gates queueing via shouldQueueOptimisticCodexUserEntry().
    • docs/codex-rewrite-render/submit-queue-debug.md already hints that Codex optimistic submit should be modeled as its own surface, not as an indistinguishable committed entry.

    Operational note: the cited debug bundles were rotated/pruned during investigation, so a future fix should capture a fresh repro fixture rather than relying on those bundle paths.

  3. Juliusolsson05
    closed this as completedin #252on May 20, 2026
  4. Juliusolsson05
    added 2 commits that reference this issue on Jul 7, 2026

    fix(rendering): address 4-agent review of #492 — block-grain suppress…

    65845e0

    fix(replay): address 4-agent review of the #493 stack — require the p…

    7e13284
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions