[Bug]: Agents panel opens at the oldest subagent on every thread switch, never the newest
メンテナーはふだん 1 日以内に返信
まだ誰も着手していません。
評価
- 難易度
- 2/5
- 見積もり時間
- 1〜3時間
- 初心者へのやさしさ
- 66/100
- issue の種類
- バグ
- 明瞭さ
- 明確に書かれている
- 活発さ
- 活発
- 技術スタック
- react, typescript
- 領域
- frontend
調査の方向性
apps/web/src/components/AgentsPanel.tsxから始めて、threadやタブが切り替わったときにScrollAreaがどのようにマウントされるかを調べてください。packages/client-runtime/src/state/subagentRuntime.tsを確認し、一覧の順序を確かめてください。新しく開いたAgentsパネルに最新のagentが表示されるよう、合意した初期位置の動作を実装してください。その後、多数のsubagentsを含むthreadで動作を確認し、CONTRIBUTING.mdの要件に従って変更前後のスクリーンショットを撮影してください。
索引モデルが issue の本文から書いたものです。
説明
Before submitting
- I searched existing issues and did not find a duplicate.
- I included enough detail to reproduce or investigate the problem.
Area
apps/web
Steps to reproduce
- Open a thread that has spawned many subagents. 20+ makes it obvious; I routinely have tens per thread.
- Open the right panel's Agents tab. The roster renders oldest-first, so the newest agent is at the very bottom.
- Scroll to the bottom to see the agent that is actually running.
- Switch to another thread and switch back. The same thing happens when switching the right panel to Files and back, or hiding and showing the right panel.
- Look at the Agents roster.
Expected behavior
Opening the Agents panel should land on the newest subagent, at the bottom of the list, because that is the one doing work right now. The oldest agent in a 30-agent roster finished twenty minutes ago and is the least useful thing to show.
A per-thread restored position would be an acceptable alternative for threads I have already visited, but a thread opened for the first time should still start at the newest agent rather than the oldest.
Actual behavior
The roster always mounts at the top, showing the oldest subagent. Every thread switch costs a manual scroll to the bottom to find the live agent. With tens of agents per thread this is constant friction.
Two things combine to produce it on current main:
- The roster is sorted oldest-first.
packages/client-runtime/src/state/subagentRuntime.ts:853sortsdirectAgentsby ascendingfirstSeenAt; workflow members sort by phase index thenagentIndex(same file, lines 784-824). The newest agent is always last. - The panel has no scroll handling at all.
apps/web/src/components/AgentsPanel.tsx:548renders a bareScrollAreawith no initial offset, no bottom anchoring, and no restoration across remounts, so it mounts atscrollTop: 0every time.
Impact
Minor bug or occasional failure
Version or commit
main @ e67abcf798f8
Environment
macOS
Logs or stack traces
Workaround
Scroll to the bottom of the Agents panel by hand after every thread switch.
Prior art, please read before marking this a duplicate
Three PRs have attempted the neighbouring problem, all closed unmerged:
- #9637 and #14512 were closed for incomplete UI verification, specifically a missing before capture.
- #14525 was closed as part of the orchestrator V2 transition (#2829), with the explicit note: "We're closing the current implementation without assuming the underlying request is resolved." That closure also said V2 removed
AgentsPanel.tsx; the file is present on currentmain, so whatever V2 did, the panel is back and still has no scroll handling.
All three solved scroll preservation, restoring the offset you last had on that thread. This issue is a different ask: land on the newest agent, including on a thread opened for the first time, where there is no saved offset to restore. The two could ship together, but preservation alone would not fix this.
Related but distinct: #8759 (right tabs should persist state and scroll position, generic, filed against the diff tab), #11571 (diff tab loses scroll position on thread switch), #17751 (Agents panel horizontal overflow, different axis).
Happy to contribute
I'm glad to pick this up and open the PR if a maintainer confirms the direction, in particular whether you want plain bottom-anchoring on mount or bottom-anchoring plus per-thread position restore. Given that two of the three prior PRs died on verification evidence rather than on the code, I'd rather agree the behavior first and then come with before/after captures that match CONTRIBUTING.md.
- 主要言語
- TypeScript
- スター
- 24.8k
- フォーク
- 6.4k
- 平均マージ
- 3時間 39分
- マージ済み PR(30日)
- 301
環境構築
このプロジェクトの開発コンテナを、あなたの GitHub アカウントでブラウザ上に起動します。
- Dockerfile・Docker Compose ファイルなし
- プルリクエストのテンプレートあり
- コントリビューションガイドを読む
はじめの一歩
- issue を最後まで読み、次にプロジェクトのコントリビューションガイドを読みます。
- 着手することを issue にコメントします — 二人が同じ作業をするのを防げます。
- リポジトリをフォークし、ブランチを切って変更します。
- issue 番号を参照したプルリクエストを送ります。
pingdotgg/t3code のほかの issue
-
bug needs-triage
難易度 2/5 1〜3時間 初心者へのやさしさ 70/100
メンテナーはふだん 1 日以内に返信
-
難易度 2/5 1〜3時間 初心者へのやさしさ 76/100
メンテナーはふだん 1 日以内に返信
-
難易度 2/5 1〜3時間 初心者へのやさしさ 72/100
pingdotgg/t3code#22819 · コメント 2 件 ·
メンテナーはふだん 1 日以内に返信
-
難易度 2/5 1〜3時間 初心者へのやさしさ 77/100
メンテナーはふだん 1 日以内に返信
-
bug needs-triage
難易度 2/5 1〜3時間 初心者へのやさしさ 62/100
メンテナーはふだん 1 日以内に返信
pingdotgg/t3code の issue をすべて見る
似ている issue
-
難易度 2/5 1〜3時間 初心者へのやさしさ 68/100
chaitin/MonkeyCode#1437 ·
メンテナーはふだん 1 日以内に返信
-
難易度 2/5 1〜3時間 初心者へのやさしさ 72/100
メンテナーはふだん 1 日以内に返信
-
難易度 2/5 1〜3時間 初心者へのやさしさ 69/100
carbon-design-system/carbon-ai-chat#2615 ·
メンテナーはふだん 1 日以内に返信
-
e2e-failure ready-to-code
難易度 2/5 1〜3時間 初心者へのやさしさ 76/100
redhat-developer/rhdh-plugin-export-overlays#4486 · コメント 1 件 ·
メンテナーはふだん 1 日以内に返信
-
[Bug]: fileUploadMatrix.test.ts URL case does a real DNS lookup and fails offline対応中かも @r2jaff が今日担当しました。 オープン
難易度 2/5 1〜3時間 初心者へのやさしさ 72/100
ComposioHQ/composio#5054 ·
メンテナーはふだん 1 日以内に返信