Skip to content

High priority: bare left/right arrow hijacks cursor key for session navigation, discarding in-progress input (data loss) #4147

Description

@NedAnd1

Summary (high priority — causes data loss)

In the interactive CLI, the bare left/right arrow keys are overloaded for session navigation. Specifically:

  • Left arrow opens the Sessions sidebar.
  • A second left arrow within ~70–450 ms starts a new session (a double-tap gesture; the timing window is hardcoded).
  • Right arrow jumps to the Agents tab.

This overloads the single most fundamental cursor key in any text field, and — most importantly — it silently discards in-progress input (a correction/follow-up I was composing), with no confirmation and no auto-stash.

Core principle: bare arrow keys should not be app keybindings in a CLI

Binding bare (unmodified) arrow keys to application actions is a fundamental anti-pattern for a terminal/CLI program. In a text interface the arrow keys have exactly one universally understood job — move the cursor. Users rely on that contract from every shell, REPL, and terminal editor. Any application-level navigation (sidebars, tabs, session switching, new session) should be bound to a modifier or leader chord (e.g. ctrl+…, or the existing ctrl+x → … pattern), never to a naked arrow key. Overloading bare arrows — especially with a destructive action — guarantees accidental, muscle-memory-driven mistakes.

Why this is high priority

  • Data loss: while composing a correction or follow-up (often while the agent is working), reaching for the arrow key out of habit triggers navigation / a new session and destroys the correction I was in the middle of writing. Silent loss of user input to a stray cursor keypress is a serious defect, not a cosmetic one.
  • Violates universal expectations: left/right arrows mean "move the cursor" in every shell, editor, and text field. Overloading them — especially with a destructive double-tap gesture — breaks muscle memory everyone has.
  • No escape hatch: there is no setting to disable or rebind this in /settings or settings.json, and the binding is not listed in the public keyboard-shortcut help. It's effectively hidden and unavoidable.

Steps to reproduce

  1. Start copilot (interactive).
  2. Press Left (for example while composing or correcting a prompt, or while the agent is working).
    • The Sessions sidebar opens.
  3. Press Left again quickly (within ~70–450 ms).
    • A new session is started and any in-progress prompt/correction is discarded.

Note: the exact conditions under which a bare arrow is captured for navigation vs. cursor movement are not documented; the observed effect is that a correction in progress can be lost.

Expected behavior

  • Bare left/right arrows should only move the cursor. They should never trigger navigation or start a new session.
  • In-progress input must never be discarded without confirmation or an automatic stash.

Suggested fixes (any one resolves it)

  1. Don't bind bare left/right to navigation — require a modifier or leader chord (e.g. ctrl+x → …, consistent with the existing ctrl+x → h to hide the sidebar).
  2. Add a setting to disable arrow-key session navigation.
  3. Never discard in-progress input without confirmation or auto-stash.
  4. At minimum, remove the destructive double-tap-left → new-session binding.

Environment

  • Copilot CLI: 1.0.71-3
  • OS: Windows

Metadata

Metadata

Assignees

No one assigned

    Labels

    area:input-keyboardKeyboard shortcuts, keybindings, copy/paste, clipboard, mouse, and text inputarea:sessionsSession management, resume, history, session picker, and session state

    Type

    Fields

    No fields configured for Bug.

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions