Clicking a window's bar shuts its panel; a pasted prompt shows without its tags - #63
Merged
Merged
Conversation
The bar only brought the window into view, keeping whatever panel was open -- so getting back to Claude alone meant finding the one lit toggle among three and clicking it again. The bar is the biggest target a window has, and the top bar's tabs already meant "back to Claude" through `revealClaude`; the window's own bar now means the same, through the same function. A separate prop rather than changing `onReveal`: the Cmd+arrow walk goes through `onReveal` and steps *through* the panels, and a panel that shut as the walk arrived at it would be a stop you could never reach. The bar's existing exclusions stand, so a panel's own controls in the bar -- terminal tabs, the todo and files bars, the toggles, the × -- still do their own job. The bar's hover text says which of the two a click will do. Measured on a scratch instance with a real click at the window's name: with terminals, todos or files open, the click left Claude alone in the window and the keyboard in Claude's terminal; a click on a terminal's own tab left the panel open. The same at 390px, where the panel had the whole window. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
…s it in Claude Code records a paste as `<pasted_content id="7b6d">` ... `</pasted_content id="7b6d">` in the user record -- the id on the closing tag too -- while the `last-prompt` beside it is the bare text. The window's task line reads the user record, so it showed the tags around the words. `INJECTED` let it through because `_` and the attribute are both outside the shape it tests, and that is right: a paste is the prompt, not machinery. So the tags are stripped and the rest kept, including anything typed around the paste. Measured in this worktree's own transcript: the record read "\n\n<pasted_content id=\"7b6d\">\nPressing on the top bar ...\n</pasted_content id=\"7b6d\">\n". The test uses it verbatim and fails without the fix with the tags in the received string. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Clicking a window's bar shuts its panel and goes back to Claude
The bar only brought the window into view, keeping whatever panel was open --
so getting back to Claude alone meant finding the one lit toggle among three
and clicking it again. The bar is the biggest target a window has, and the top
bar's tabs already meant "back to Claude" through
revealClaude; the window'sown bar now means the same, through the same function.
A separate prop rather than changing
onReveal: the Cmd+arrow walk goesthrough
onRevealand steps through the panels, and a panel that shut as thewalk arrived at it would be a stop you could never reach. The bar's existing
exclusions stand, so a panel's own controls in the bar -- terminal tabs, the
todo and files bars, the toggles, the × -- still do their own job. The bar's
hover text says which of the two a click will do.
Measured on a scratch instance with a real click at the window's name: with
terminals, todos or files open, the click left Claude alone in the window and
the keyboard in Claude's terminal; a click on a terminal's own tab left the
panel open. The same at 390px, where the panel had the whole window.
A pasted prompt shows in its window without the tags Claude Code wraps it in
Claude Code records a paste as
<pasted_content id="7b6d">...</pasted_content id="7b6d">in the user record -- the id on the closing tag too -- while thelast-promptbeside it is the bare text. The window's task line reads the userrecord, so it showed the tags around the words.
INJECTEDlet it throughbecause
_and the attribute are both outside the shape it tests, and that isright: a paste is the prompt, not machinery. So the tags are stripped and the
rest kept, including anything typed around the paste.
Measured in this worktree's own transcript: the record read
"\n\n<pasted_content id="7b6d">\nPressing on the top bar ...\n</pasted_content
id="7b6d">\n". The test uses it verbatim and fails without the fix with the
tags in the received string.
🤖 Generated with Claude Code