Open files in external editor from within Copilot CLI

[torumakabe]

Describe the feature or problem you'd like to solve

There is currently no dedicated way to open an arbitrary project file in an external editor from within an active Copilot CLI session. Ctrl+G only edits the prompt, and ! shell mode does not support full-screen interactive editors (TUI). While GUI editors like VS Code can be launched separately (e.g., ! code <file>), this shifts focus to a different window and breaks the flow of the terminal-centric conversation. Users who want to manually review or edit a file mid-conversation should be able to do so without leaving the Copilot CLI terminal.

Proposed solution

Add a slash command (e.g., /edit <file>) or keyboard shortcut that temporarily yields terminal control to the user's $EDITOR / $VISUAL for editing a specified file path. On editor exit, Copilot CLI resumes its TUI and the conversation continues.

This would reuse and generalize the existing Ctrl+G mechanism — which already launches $EDITOR for prompt editing — to support arbitrary file paths.

Key behaviors:

• Respects $EDITOR / $VISUAL environment variables
• Works cross-platform (Unix and Windows), unlike Ctrl+Z job control which is Unix-only
• Copilot CLI suspends its TUI rendering during the editor session and restores it on editor exit
• Optionally (as a future enhancement), Copilot CLI could notice the file was changed and offer to include the diff as context

Synergy with @ file mentions: The @ file search feature is already one of the best parts of the Copilot CLI experience — it makes referencing files in conversation fast and intuitive. Combining @ with /edit (e.g., typing @ to search for a file, then opening it in your editor) could create a seamless "find → edit → continue conversation" loop entirely within the CLI. This pairing would significantly elevate the terminal-native development experience that Copilot CLI aims to provide.

Example prompts or workflows

1. Review and tweak Copilot's changes: Copilot modifies src/auth.ts. Before continuing, the user types /edit src/auth.ts to open it in their editor, reviews the changes, makes a small adjustment, saves and quits — Copilot CLI resumes immediately and the conversation continues with the updated file.

2. Fill in domain-specific values: User asks Copilot to scaffold a config file. The result is close but needs values only the user knows. User types /edit config.yaml, fills in the details by hand, and then tells Copilot to continue using the updated file.

3. Find and edit with @: User types /edit @ and searches for a config file by name. The matched file opens in their editor, they make a quick change, and return to the conversation — all without leaving Copilot CLI.

Additional context

• Existing partial workaround: Ctrl+Z (Unix job control) allows suspending Copilot CLI to use editors from the shell, but this is unavailable on Windows.
• Cross-platform issue with ! shell mode: Running interactive editors via ! fails across platforms — on Windows, ! edit <file> returns an invalid handle error; on Linux, ! vim <file> warns "Output is not to a terminal" / "Input is not from a terminal".
• Similar approach in another AI CLI tool: Gemini CLI added PTY-based interactive shell support (v0.9.0), enabling TUI apps like vim to run within the CLI session.
• Related issues:
  • Terminal freezes after opening external editor via Copilot CLI (ctrl+y / ctrl+g) #1798 — Terminal freezes after opening external editor via Ctrl+G (stability of the existing handoff mechanism)
  • Open IDE in Session Working Directory (/ide enhancement or keyboard shortcut) #1308 — Request to open IDE in session working directory (similar need, different approach)

[yelper]

This is a fantastic suggestion and I'd like to +1 it in so many words! The "edit" command becomes an explicit signal to the copilot process to suspend while contributions are made, which can nicely tackle some weird async behavior when co-authoring.