[Bug]: `container exec -it` leaves host tty with OPOST|ONLCR, breaking tmux/TUI rendering

[dcvijetic-TT]

I have done the following

• I have searched the existing issues
• If possible, I've reproduced the issue using the 'main' branch of this project

Steps to reproduce

container exec -it <container> sh -c 'stty raw -echo; printf "\033[2J\033[H0123456789\nX\r\n"; sleep 3; stty sane'

Expected: X appears directly after 9, because the inner tty is raw and a bare LF only moves down a row.
Actual: X appears at column 0 of the next line.

Running the same printf on the host alone puts X after 9.

Problem description

Summary

On macOS, the host tty stays in OPOST|ONLCR mode during an interactive session. As a result, every bare LF the container sends is turned into CR LF before it reaches the terminal. Full-screen programs that use LF to move the cursor down one row (tmux, vim, Ink-based TUIs such as Claude Code) then draw at column 0 instead of the current column. You see this as:

• a new tmux pane split to the right painting over the left pane
• repaints only partly erasing earlier text, so stale characters show through
• the same corruption without tmux, running a TUI directly in the container

None of this happens when the same programs run on the host.

Cause

ProcessIO.create puts the host tty into raw mode with Terminal.setraw():
https://github.com/apple/container/blob/dc276ee/Sources/Services/ContainerAPIService/Client/ProcessIO.swift#L52

public func setraw() throws {
    var attr = try Self.getattr(descriptor)
    cfmakeraw(&attr)
    attr.c_oflag = attr.c_oflag | tcflag_t(OPOST)
    try fromSyscall(tcsetattr(descriptor, TCSANOW, &attr))
}

https://github.com/apple/containerization/blob/8b8cd7e/Sources/ContainerizationOS/Terminal.swift#L143-L148

On macOS, cfmakeraw() clears only the OPOST bit in c_oflag. It does not touch ONLCR, which is on by default. setraw() then turns OPOST back on, so the host tty ends up with OPOST|ONLCR and translates output again.

The guest pty already applies whatever output processing the container program asked for. tmux, for example, sets its own tty to -opost. So translating a second time on the host is always wrong for interactive sessions. For comparison, Docker's host-side raw mode (moby/term MakeRaw) clears OPOST completely.

Workaround

Clear ONLCR on the host tty before calling container. setraw() never changes that bit, so the setting survives:

saved=$(stty -g); trap 'stty "$saved"' EXIT
stty -onlcr
container exec -it <container> zsh

With this in place, the reproduction above prints X after 9, and tmux and TUI rendering inside the container are correct.

Related

• Glitches in an interactive shell spawned via 'podman exec', but not 'podman run', due to the presence of OPOST in the outer PTY and missing ONLCR in the inner PTY containers/toolbox#14: the same class of bug with podman exec (OPOST left on in the outer tty caused tmux/vim glitches)
• fix: run interactive pty in raw mode so stdout is not truncated containerization#845, [Bug]: container run --interactive wrongly (de?)allocates stdin/stdout/terminal? #1148: guest pty raw mode that deliberately keeps OPOST/ONLCR

Environment

- `container --version`: CLI version 1.4.1 (build: release, commit: unspeci)
- macOS: 26.6.2
- Terminal: kitty 0.49.0 created by Kovid Goyal 
- Guest: Ubuntu 24.04, tmux 3.4

Code of Conduct

• I agree to follow this project's Code of Conduct

[guanchzhou]

The diagnosis looks right: ProcessIO.create() puts the host tty through Terminal.setraw(), and ContainerizationOS turns OPOST back on after cfmakeraw() without clearing ONLCR, so the host does a second LF→CRLF translation.

I can send a PR. Before coding: which repo should own the fix?

1. apple/container — after setraw() in ProcessIO.create(), clear ONLCR on the host fd (and restore on exit). Local to the container exec -it call site.
2. apple/containerization — add a distinct host-side raw-mode API that does not re-enable ONLCR. fix: run interactive pty in raw mode so stdout is not truncated containerization#845 intentionally keeps OPOST|ONLCR on the guest pty slave, so changing setraw() in place would collide with that.

I prefer (1) unless you want the host/guest split in ContainerizationOS. Happy to follow either.

[am-saksham]

Just chiming in from the sidelines! I'd highly recommend going with Option 2 (apple/containerization).

Since setraw() currently preserves OPOST|ONLCR specifically for guest PTYs, adding a distinct host-side API (e.g., setHostRaw()) feels like the cleanest architectural fix. It creates a clear boundary between host and guest TTY handling and ensures that any future consumers of ContainerizationOS won't stumble into this same double-translation issue.