Terminal failures can trigger opaque base64 patch recovery instead of a clear handoff

Summary

When a Codex terminal or PTY path fails, the agent can fall back to moving scripts or patches through base64-encoded shell commands. That recovery path is hard to inspect and can itself fail because of nested shell quoting, leaving the user unsure whether the terminal, transport, or patch is corrupted.

Three reports across April–June show the same recovery shape:

• Current GPT-5.6 Max feedback: 019f0009-533c-7c41-9d86-601235eb9f6b
• May feedback: 019e429c-3083-7eb2-aff6-973da9554ce3
• April session: 019d8952-c257-7501-af61-2e6eae01967b

The May investigation identified a concrete quoting failure: nested shell quoting stripped quotes around the base64 payload, while stronger escaping succeeded. The current report began with an apparently broken PTY and then degraded into base64-based patch recovery. These may not share the original PTY root cause, but they share the same unsafe and opaque recovery surface.

Impact

• Users cannot easily review the script or patch being transferred.
• Quoting corruption can make the fallback fail or modify the wrong content.
• The agent may continue attempting increasingly opaque recovery instead of returning a clear terminal failure.
• Logs do not clearly distinguish the original PTY failure from the selected recovery transport and any later quoting error.

Proposed behavior

1. A PTY or terminal failure should not silently downgrade into an opaque base64 patch path.
2. Recovery should first attempt to restore or recreate the terminal session.
3. If recovery is not possible, return a clear handoff with the original error and safe next steps.
4. Prefer native upload, patch, or stdin transfer primitives over nested base64 shell commands.
5. If an encoded transport is unavoidable, show the source artifact, verify its checksum, and use an argument-safe invocation rather than interpolated nested quoting.
6. Record the original terminal error and the chosen recovery transport separately in diagnostics.

Acceptance criteria

• A forced PTY failure cannot silently transition into an uninspectable patch path.
• The user receives either a restored terminal or an explicit failure/handoff.
• Remote scripts and patches remain inspectable before execution.
• Encoded transfers use argument-safe transport and integrity verification.
• Diagnostics identify the PTY failure, recovery decision, and any later transport error.
• Regression coverage includes payloads containing spaces, quotes, newlines, and shell metacharacters.

Reproduction evidence

The reports are currently session-based rather than a minimal deterministic repro. Please use the three feedback/session IDs above to compare:

• the original terminal/PTY failure;
• the decision to select base64 recovery;
• the exact command construction and quoting;
• whether the fallback mutated files before validation.

This issue intentionally does not group fully unrecoverable threads or compaction failures unless their traces show the same recovery transport.