Sign up
View stargazersSign up

[Bug]: Goal status becomes an unlabeled strip behind Tasks during a run#25379

opened3d agobyMmaheshrijal

Before submitting

  • I searched existing issues and did not find an exact duplicate.
  • I included enough detail to reproduce or investigate the problem.

Area

apps/web (observed in the desktop app)

Steps to reproduce

  1. Open a Codex thread and start a goal that keeps the agent working and produces a task list. My reproduction used:

    /goal this is a sample goal, run for 5 minutes. And pretend to run 3 different tasks. Want to check if a bug exists.

  2. Wait until the agent has created its task list and the Tasks row appears above the composer.

  3. Move the pointer away from the thin strip above Tasks.

  4. Hover that strip, then move away again.

The agent must actually create/update a plan for the Tasks row to appear; the prompt wording alone does not guarantee that.

Expected behavior

The goal's presence and status should remain discoverable while Tasks is visible. A collapsed control should make it apparent that it contains the goal and can be expanded.

Actual behavior

Tasks remains visible, but the goal row becomes a thin, unlabeled strip above it. The goal's status, objective and usage are hidden. Hovering the strip reveals the full Pursuing goal row; moving away collapses it again. It looks as though the goal row is clipped or missing.

This occurs with an actively running goal. I also observed it with a completed goal during a subsequent working turn. For Codex, the goal becomes visible again when the turn finishes and the Tasks row disappears.

Impact

Minor bug: the goal status is difficult to discover during execution. No loss of goal state or interruption of goal execution was established.

Version or commit

T3 Code 0.1.2, confirmed by both the installed desktop app and its local server.

Environment

macOS 27.0.1, T3 Code (Beta) desktop, Codex provider.

Source findings

The behavior follows the banner-stack ordering:

  • ChatComposer prepends the Tasks item before the other banners. Tasks and Goal both have priority: "activity".
  • ComposerBannerStack uses a stable priority sort and shows the first item. Tasks wins the tie; Goal goes into the collapsed stack.
  • ComposerBanner.Peek is an empty h-3 button, which explains the unlabeled strip.
  • Task selection removes the Codex Tasks row when its run settles, allowing Goal to become the front item.

The same Tasks-prepending logic exists in v0.1.2. Current-main source was inspected at 2763bbeb739e64c181d7800ddb9c1459f678dea4; a separate current-main client reproduction was not performed.

Related reports

  • #22819 concerns the shadow in the same Goal + Tasks layout, rather than the goal being undiscoverable.
  • #24279 concerns explicitly requested usage-limit results hiding behind Tasks.
  • #10164 concerns a Compact action hidden behind the same peek.

The existing single-front-banner design in #18919 is acknowledged. This report describes the discoverability problem and does not prescribe a layout change.

Workaround

Hover or click the thin strip above Tasks to expand the hidden goal row.

Reported from user-provided recordings and source inspection. Prepared with GPT-6 Astra via Codex in T3 Code; independently reviewed with Claude Opus 5.5. No local fix applied.

Recording

Active goal with three tasks: moving the pointer over and away from the strip reveals and hides the goal row.

https://github.com/user-attachments/assets/764449da-6cdf-4340-bde1-75a296436c55

https://github.com/user-attachments/assets/fb2d0c7d-f6cc-4a0f-b7f4-5b6d09528cb1