feat: add thread info modal with rename + context usage#528
feat: add thread info modal with rename + context usage#528vforsh wants to merge 9 commits intoDimillian:mainfrom
Conversation
This reverts commit 2f38dfa.
|
|
@codex review |
![chatgpt-codex-connector[bot]](https://avatars.githubusercontent.com/in/1144995?s=60&v=4){kind=small}
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: a54e5034cb
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
|
@codex review |
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: 56a4d2410c
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
| {threadInfoOpen && | ||
| activeThreadInfo && | ||
| onRenameActiveThreadName && | ||
| onGenerateActiveThreadName ? ( |
There was a problem hiding this comment.
Because threadInfoOpen is never cleared when activeThreadInfo becomes falsy, the modal can silently unmount (for example when the user navigates to workspace home or the active thread is temporarily unset) while the open flag stays true; as soon as another thread becomes active, the modal reappears automatically without an explicit click. This creates an unexpected cross-thread modal reopen behavior that is user-visible and confusing.
Useful? React with 👍 / 👎.
There was a problem hiding this comment.
Fixed in bb5c1e3. Added a useEffect in MainHeader to reset threadInfoOpen whenever activeThreadInfo becomes falsy, so the modal cannot silently stay open and auto-reappear on a different thread context.
| onClick={async () => { | ||
| await navigator.clipboard.writeText(thread.threadId); | ||
| setThreadIdCopied(true); |
There was a problem hiding this comment.
This copy action awaits navigator.clipboard.writeText without error handling, so environments where clipboard writes are blocked or unavailable will produce an unhandled rejected promise and no user feedback; the same pattern is also used for the project-directory copy button. Wrapping these writes in try/catch (like existing thread-copy flow) avoids noisy runtime errors and makes failure behavior predictable.
Useful? React with 👍 / 👎.
There was a problem hiding this comment.
Fixed in c435fa8. Wrapped both thread info copy actions in a shared try/catch clipboard helper, preventing unhandled promise rejections when clipboard write is unavailable, and added inline error feedback (Could not copy to clipboard.).
2 participants
Summary
Thread infomodal action in top-right header (left ofCopy thread)118.1k / 258.4k)Verification
agent-device: