[BUG] Terminal state not restored on --resume --agent exit -- DECCKM + Kitty KP regression in v2.1.113 (Windows Terminal + PowerShell)

Summary

Issue #39319 was closed 2026-04-16 with "Fixed as of v2.1.85." The terminal state corruption is still happening in v2.1.113, with two confirmed triggers on Windows Terminal + PowerShell 7.5.

This is not a duplicate of #39319 — that issue was closed as FIXED. This is a regression report with new trigger identification and new root-cause detail.

---

Environment

• OS: Windows 11
• Terminal: Windows Terminal 1.24 (full Kitty keyboard protocol support)
• Shell: PowerShell 7.5
• Claude Code: v2.1.113 (latest as of 2026-04-18)

---

Confirmed Triggers

Trigger 1: --resume --agent

claude --resume <session-id> --agent dual-pipeline-manager --model claude-opus-4-7

After session exits: PowerShell prompt shows [rupt appended (or similar escape residue).

Trigger 2: --fork-session (reported in #42084 comment 2026-04-18)

claude --resume <session-id> --fork-session --agent <name> --model claude-opus-4-7

After fork completes: continuous [O[I[O[I[O... flood in parent shell.

---

Root Cause of the [rupt Artifact (new information)

The [rupt in the PS prompt is DECCKM residue, not Kitty keyboard protocol.

When Claude Code enables application cursor key mode (CSI ? 1 h, DECCKM), arrow keys send ESC O A instead of ESC [ A. If DECCKM is not restored on exit (CSI ? 1 l), subsequent Up-arrow presses in the shell send ESC O A to the input buffer. PowerShell's PSReadLine:

1. Consumes ESC invisibly
2. Prints O as [O due to bracketed input mode interaction
3. Prints the literal key name characters that follow

Result: [O + rupt → [rupt visible in the PS prompt on the next keypress.

This is a separate mode from the Kitty keyboard protocol and requires a separate reset sequence: CSI ? 1 l (DECRST DECCKM).

---

Terminal Modes That Need Restoring

The fix in v2.1.85 addressed Kitty keyboard protocol cleanup on clean exit. The following modes are not restored on --resume --agent or --fork-session exit:

| Mode | Enable sequence | Required reset |
|------|----------------|----------------|
| Kitty KP | CSI = flags ; 1 u | CSI < u (pop) + CSI = 0;1u (push-0) |
| DECCKM (cursor keys) | CSI ? 1 h | CSI ? 1 l ← missing |
| X10 mouse | CSI ? 1000 h | CSI ? 1000 l |
| Button-event mouse | CSI ? 1002 h | CSI ? 1002 l |
| Any-event mouse | CSI ? 1003 h | CSI ? 1003 l |
| SGR mouse extension | CSI ? 1006 h | CSI ? 1006 l |
| Focus events | CSI ? 1004 h | CSI ? 1004 l |
| Bracketed paste | CSI ? 2004 h | CSI ? 2004 l |
| Alternate screen | CSI ? 1049 h | CSI ? 1049 l |
| Cursor visibility | CSI ? 25 l | CSI ? 25 h |
| Full soft reset | — | CSI ! p (DECSTR) |

The v2.1.85 fix appears to handle Kitty KP on the normal exit path but misses DECCKM and does not run on --resume --agent or --fork-session session transitions.

---

Workaround (current)

We implemented a Stop hook in our project that writes these reset sequences to stderr on every Claude session end. Also wrapping the claude command in a PowerShell function that resets terminal state after the binary exits.

This should not be required — Claude Code should restore its own terminal state on exit in all code paths.

---

Related Issues

| Issue | Status | Notes |
|-------|--------|-------|
| #39319 | CLOSED (claimed fixed v2.1.85) | Windows-specific Kitty KP — regression |
| #38761 | CLOSED (fix shipped) | Primary canonical fix issue |
| #42084 | OPEN | --fork-session trigger, filed today |
| #41745 | OPEN | PowerShell dirty exit still present on v2.1.90 |
| #1509 | OPEN since June 2025 | SGR sequences leaking while Claude runs |

Please do not close this as a duplicate of #39319. That issue was closed as FIXED. This is evidence the fix is incomplete.

---

Ask

1. Extend terminal state restore to cover the --resume --agent and --fork-session exit paths (not just clean process exit)
2. Add DECCKM reset (CSI ? 1 l) to the restore sequence — it was missing from the v2.1.85 fix
3. Run DECSTR (CSI ! p) as belt-and-suspenders after targeted resets
4. Test on Windows Terminal specifically — macOS/Linux terminal emulators handle partial mode restoration more gracefully