Claude chat input on macOS: ⌘A selects full conversation, and caret can’t be placed inside existing text

[marmey83]

Summary

In Claude chat input on macOS, core text-editing interactions are broken: ⌘A selects the entire conversation instead of the active input text, and clicking inside typed input does not move the caret.

Problem

While composing prompts in Claude chat, users cannot reliably edit existing input text. The selection and caret behavior appears to target the full conversation surface rather than the active text input.

Expected behavior

• Pressing ⌘A while focus is in the Claude input should select only the current input text.
• Clicking/tapping within already typed text should place the caret at that position for mid-text edits.

Actual behavior

• Pressing ⌘A selects the full conversation instead of only input text.
• Clicking/tapping inside already typed text does not place the cursor there, blocking mid-text editing.

Reproduction steps or desired workflow

1. Open Claude chat in Warp.
2. Type a longer prompt in the input.
3. Try clicking in the middle of the typed text.
4. Press ⌘A.
5. Observe that caret placement/editing fails and the full transcript gets selected.

Artifacts

None attached.

Warp version

v0.2026.05.06.15.42.stable_05

Operating system

macOS 15.7.3 (build 24G419)

[oz-for-oss]

@marmey83

Here's what I found while triaging this issue:

This looks like a Warp input-focus/editing bug in the Claude/agent composer rather than expected behavior.

I have a few follow-up questions before I can narrow this down:

1. Can you attach a short screen recording showing the click inside the typed prompt and then ⌘A selecting the conversation?
2. Which Claude surface are you using when this happens: Warp cloud-mode chat with a Claude model, or a local/full-terminal-use Claude Code session?

Reply in-thread with those details and the triage workflow will automatically re-evaluate the issue and update the diagnosis, labels, and next steps.

Maintainer details

I concluded that claude/agent chat input on macOS appears to route caret placement and ⌘A select-all to the conversation surface instead of the active input editor..

Triage summary

This is a macOS bug report for Claude/agent prompt editing in Warp v0.2026.05.06.15.42.stable_05: clicking inside typed prompt text reportedly does not move the caret, and ⌘A selects the full conversation instead of the current input text.

Reproducibility

Medium. The report includes a concrete version, OS, and step sequence, but there is no media artifact and the exact Claude surface is still unclear.

Likely area

The behavior points to input focus/selection routing rather than expected editor behavior. The agent/cloud-mode input renders the shared editor inside container wrappers; if a parent left-click handler or conversation surface receives the event instead of the editor, the editor caret will not move. Because the editor registers its own Select All action, ⌘A selecting the conversation also suggests focus or select-all dispatch may be landing outside the editor.

Code pointers

• app/src/terminal/input/agent.rs
• app/src/terminal/input/common.rs
• app/src/terminal/input.rs
• app/src/editor/view/element.rs
• app/src/editor/view/mod.rs
• app/src/app_menus.rs

Duplicate check

I enumerated all open issues and recently closed issues and did not find a duplicate cluster meeting the repository duplicate threshold.

Remaining ambiguity

A short recording and the exact Claude surface are needed before root-cause confidence or owner routing can be raised.

Question reasoning

1. Can you attach a short screen recording showing the click inside the typed prompt and then ⌘A selecting the conversation? — The symptom is visual/focus-related, and media would confirm which surface receives focus and selection during the failure.
2. Which Claude surface are you using when this happens: Warp cloud-mode chat with a Claude model, or a local/full-terminal-use Claude Code session? — The likely code path differs between cloud-mode composer, agent view input, and CLI agent rich input, and the report only says Claude chat.

This is my automated analysis and may be incorrect. A maintainer will verify the details.

Powered by Oz

[marmey83]

its unfortunately not possible to add screen recordings here

[oz-for-oss]

@marmey83

Here's what I found while triaging this issue:

A screen recording is not required for the next step; a short text clarification is enough.

I have a few follow-up questions before I can narrow this down:

1. Is this happening inside Claude Code's own terminal UI after running claude, or inside Warp's Rich Input composer opened from the CLI agent toolbar/Ctrl+G?

Reply in-thread with those details and the triage workflow will automatically re-evaluate the issue and update the diagnosis, labels, and next steps.

Maintainer details

I concluded that claude/CLI-agent input on macOS appears to route select-all and mouse clicks to the surrounding terminal/conversation instead of the active prompt input, but the exact affected surface still needs clarification..

Triage summary

The report describes a macOS input-routing bug while composing in Claude: ⌘A selects the surrounding conversation and mouse clicks do not place the caret inside the current prompt. The supplied Warp build and OS version make this plausible, but the affected input surface is still ambiguous.

Reproducibility

Medium. The steps are concise and target a specific Warp build (v0.2026.05.06.15.42.stable_05) on macOS 15.7.3, but there is no media artifact and the report does not distinguish Claude Code's in-terminal UI from Warp's CLI-agent Rich Input composer.

Code findings

• The macOS Select All path is split between the editor and terminal block list. app/src/editor/view/mod.rs binds the editor's Select All action, while app/src/terminal/view/init.rs registers terminal-level Select All for non-empty terminal block lists. If the editor is not focused, app/src/terminal/view.rs can route Select All to SelectAllBlocks, matching the full-conversation selection symptom.
• For raw Claude Code/alt-screen input, mouse events are only passed through when SGR mouse tracking and Warp mouse reporting are active (app/src/terminal/alt_screen/mod.rs, app/src/terminal/alt_screen/alt_screen_element.rs). Otherwise Warp handles clicks as terminal selection/focus events; the long-running block path has similar forwarding/interception logic in app/src/terminal/block_list_element.rs.
• If the problem is instead in Warp's CLI-agent Rich Input composer, that UI reuses EditorView in app/src/terminal/input/cli_agent.rs and wraps it with the shared focus handler in app/src/terminal/input/common.rs, so focus propagation around that wrapper would be the first place to inspect.

Duplicate check

No duplicate should be applied. #11401 is related to richer in-line command editing, but it is an enhancement request for broader selection/cursor capabilities rather than the same macOS Claude input bug, and the duplicate search did not find two matching open or recently closed issues.

Remaining ambiguity

The main blocker is identifying which Claude input surface is affected, because raw terminal/alt-screen input and Warp's Rich Input composer use different code paths.

Question reasoning

1. Is this happening inside Claude Code's own terminal UI after running claude, or inside Warp's Rich Input composer opened from the CLI agent toolbar/Ctrl+G? — These two surfaces use different input paths; the answer determines whether maintainers should investigate terminal mouse/key forwarding or the Warp editor wrapper used by CLI-agent Rich Input.

This is my automated analysis and may be incorrect. A maintainer will verify the details.

Powered by Oz

[oz-for-oss]

@marmey83

Here's what I found while triaging this issue:

The screenshot helps: it looks like the focus is in Claude Code's native terminal prompt, while Warp's Rich Input composer is available in the toolbar. As a workaround, try the Rich Input button or Ctrl-G for longer prompts, since that path should use Warp's normal text editor behavior.

I have a few follow-up questions before I can narrow this down:

1. Does the same Cmd+A and click-to-place-caret behavior happen after opening Warp's Rich Input composer with the toolbar button or Ctrl-G?

Reply in-thread with those details and the triage workflow will automatically re-evaluate the issue and update the diagnosis, labels, and next steps.

Maintainer details

I concluded that claude Code's native terminal prompt on macOS is receiving focus instead of Warp's rich input editor, so Cmd+A and click-to-caret behave like terminal selection/PTY mouse handling rather than normal text editing..

Triage summary

The screenshot is helpful and shows the cursor in Claude Code's native terminal prompt, with Warp's CLI-agent toolbar and Rich Input button visible. That makes this look more like a terminal/CLI-agent input routing issue than a failure in Warp's EditorView-backed rich input composer.

Evidence

• The report includes concrete macOS and Warp version details plus a minimal reproduction path for Cmd+A and mouse caret placement.
• The screenshot shows a long-running Claude Code session prompt (>), not an open Warp Rich Input composer.
• Warp registers a macOS terminal-level Select All blocks action separately from the editor Select All action, and the editor action only applies when EditorView has focus.
• For active long-running blocks, mouse clicks/drags are handled through terminal block selection or forwarded to the PTY as terminal mouse events, so click-to-caret depends on the foreground CLI/TUI surface rather than Warp editor hit-testing.

Likely cause

The affected input appears to be Claude Code's native PTY prompt. In that mode, Cmd+A is not handled by Warp's editable prompt composer, and clicking inside the line is not guaranteed to place a text caret unless the foreground CLI handles the mouse event. Warp's Rich Input path is separate: it opens a CLI-agent input session, uses the Warp editor for composing, and then submits the text to the agent PTY.

Duplicate check

I scanned all open issues in warpdotdev/warp. #11401 is related because it asks for richer inline command editing, click-to-position cursor, and selection behavior, but it is broader and framed as an enhancement; I did not find the two or more close matches required to mark this as a duplicate.

Question reasoning

1. Does the same Cmd+A and click-to-place-caret behavior happen after opening Warp's Rich Input composer with the toolbar button or Ctrl-G? — This distinguishes a Claude Code native terminal prompt limitation from a Warp rich-input editor regression; the screenshot confirms the native prompt surface but not the rich-input path.

This is my automated analysis and may be incorrect. A maintainer will verify the details.

Powered by Oz

[marmey83]

it does work with Ctrl-G it has the expected behaviour. However it should be fixed in the other one as this often provides useful next steps that can be activated automatically with an arrow key. this is not available in the warps rich input composer, so it doesn'^t resolve the issue.

[oz-for-oss]

@marmey83

Here's what I found while triaging this issue:

Thanks for confirming that Ctrl-G works. This still looks actionable because Ctrl-G opens Warp's separate rich input composer, while the reported bug is in the native Claude Code prompt where next-step suggestions and arrow-key interactions are available.

Maintainer details

I concluded that claude Code's in-terminal prompt on macOS appears to be receiving neither standard macOS select-all semantics nor reliable mouse/caret routing in Warp, while Warp's Ctrl-G rich input path works but is not an equivalent replacement for this workflow..

Triage summary

This looks like a Warp bug in the Claude Code / CLI-agent terminal input path on macOS, not a general limitation of Warp's native rich input composer. The reporter confirmed that Ctrl-G rich input behaves as expected, but that workaround is not equivalent because the native Claude Code prompt exposes next-step suggestions and arrow-key interactions that the rich input composer does not.

Observed behavior

• In the Claude Code chat/input surface on macOS, pressing Cmd-A selects the full conversation/transcript rather than only the current prompt text.
• Clicking inside already-typed prompt text does not move the caret for mid-text edits.
• A screenshot was provided in the issue comments; no recording is available through the issue thread.

Reproducibility

Medium. The report includes concrete steps, Warp version v0.2026.05.06.15.42.stable_05, macOS 15.7.3, and a follow-up confirming the distinction from Ctrl-G rich input. Local macOS reproduction and the exact Claude Code renderer/protocol state are still unverified.

Likely root cause / routing notes

The affected surface appears to be the terminal-backed Claude Code prompt, while Ctrl-G opens Warp's separate CLI-agent rich input composer. Relevant code paths suggest:

• app/src/terminal/view/init.rs registers macOS Select All for terminal block selection and separately registers editor select-all through EditorView; focus/context ordering may allow Cmd-A to resolve to terminal transcript/block selection instead of the Claude prompt.
• app/src/terminal/view.rs exposes TerminalView::selected_text, selected_text_from_input, and select_all_blocks, and mirrors CLI-agent rich-input-open state into terminal keymap context.
• app/src/terminal/alt_screen/mod.rs, app/src/terminal/alt_screen/alt_screen_element.rs, and app/src/terminal/block_list_element.rs decide whether mouse events are intercepted for Warp selection or forwarded to the running TUI based on terminal modes such as mouse reporting/SGR mouse.
• app/src/terminal/view/use_agent_footer/mod.rs and app/src/terminal/cli_agent_sessions/mod.rs implement the Ctrl-G rich input path, which explains why Ctrl-G can work while the native Claude prompt still fails.
• app/src/editor/view/mod.rs and app/src/editor/view/element.rs handle correct select-all and click-to-caret behavior for Warp's native editor, so the bug likely sits in focus/keybinding/mouse routing between the terminal-backed Claude surface and Warp editor semantics rather than in the editor implementation itself.

Duplicate check

I checked all open non-PR issues. Related issues include #6868 (mouse input in Claude Code), #9159 (macOS editing shortcuts in Claude Code/TUI apps), #10353 (TUI mouse selection behavior), #11401 (inline command editing improvements), and #9179 (rich input mode switching). These overlap with parts of the behavior, but I did not find at least two open issues matching this same combined Cmd-A plus click-to-position failure on the Claude Code prompt, so I am not marking this as a duplicate.

This is my automated analysis and may be incorrect. A maintainer will verify the details.

Powered by Oz