Ctrl+G external editor spawned without job control — tmux pane_current_command stays 'claude'

Problem

When Claude Code spawns $EDITOR via Ctrl+G, the editor process inherits claude's process group instead of becoming the foreground process group leader. tmux's #{pane_current_command} (and any tooling that reads the tty's foreground pgid) continues to report claude instead of the editor.

Observed behavior

    PID    PPID    PGID   TPGID COMMAND
 104459  102601  104459  104459 claude    ← foreground pg leader
1590762  104459  104459  104459 sh        ← same pg
1590763 1590762  104459  104459 nvim      ← same pg, invisible to tmux

The spawn chain is claude → sh -c → nvim, all in PGID 104459.

Why it matters

tmux keybindings that condition on #{pane_current_command} can't distinguish between the chat input and the external editor. Example: an Enter-key intercept that sends M-Enter to insert newlines in the chat box continues firing inside nvim, bouncing the user out of insert mode on every Enter press.

More broadly, any terminal integration that relies on the foreground process group (shell prompts that read $TPGID, terminal title scripts, etc.) sees the wrong process.

Expected behavior

The editor should be spawned with setpgid() (new process group) and tcsetpgrp() (hand off tty foreground), so the tty's TPGID points at the editor while it runs. This is standard job-control behavior — what shells do when launching a foreground command.

Environment

• Claude Code 2.1.86-dev.20260327
• Linux, zsh, tmux
• $EDITOR=nvim

Workaround

Map <M-CR> → <CR> in the editor config so the tmux swap becomes transparent. Works but requires per-editor configuration and doesn't help other tooling that reads the foreground pg.