[CLI Bug] CLI leaves terminal TTY state corrupted (echo disabled/raw mode) after SIGINT or detaching with -d

[patrickryankenneth]

Description

When running the LocalStack CLI (localstack start or localstack start -d) using Podman as the backend container engine, the CLI alters the host terminal's TTY line discipline (disabling keyboard echo and switching to raw mode).

However, if the CLI process is interrupted via SIGINT (Ctrl-C) during startup, or when it forks/detaches under the -d flag, the CLI fails to restore the TTY settings to standard/cooked mode before returning control to the shell. This leaves the active user shell completely broken (character echoing is disabled, line formatting is corrupted, and keyboard inputs fail to render), forcing users to manually run reset or stty sane to recover their shell.

At minimum, detached mode (-d) should run without depending on or mutating the caller's stdin/stdout TTY state, and any terminal mode changes made during startup must be reliably restored before returning control to the shell.

---

Environment

• OS: CachyOS (Arch-based Linux)
• Shell: Bash (running inside a virtualenv)
• LocalStack CLI Version: 2026.6.0
• Container Engine: Podman 5.8.3 (rootless, mapped via DOCKER_HOST)

---

Steps to Reproduce

Scenario A (Signal Interruption):

1. Run localstack start
2. Send SIGINT (Ctrl-C) during the startup or shutdown sequence.
3. Observe that after the CLI exits, the host terminal shell's input echoing is permanently disabled.

Scenario B (Detached Mode):

1. Run localstack start -d
2. Wait for the CLI to output detaching and return control to the shell.
3. Observe that character echoing is completely broken in the active terminal window.

---

Expected Behavior

• The CLI should utilize robust signal handlers (using Python's signal / atexit modules or standard try/finally blocks) to ensure the standard terminal discipline is restored (stty sane equivalent) regardless of how the CLI exits.
• When detached mode (-d) is requested, the CLI should safely run in a non-interactive mode that does not attach to, mutate, or retain the parent shell's controlling TTY.

---

Additional Findings & Diagnostic Workaround

The issue appears to be tied specifically to the LocalStack CLI interacting with the caller's controlling TTY during startup, even when -d (detached) is supplied.

Launching the exact same detached start path through a TTY-isolated wrapper completely avoids the corruption:

LOG="$HOME/.local/state/localstack/localstack-start-$(date +%Y%m%d-%H%M%S).log"
mkdir -p "$(dirname "$LOG")"

# Running through setsid and isolating stdin prevents TTY corruption:
setsid nohup localstack start -d </dev/null >>"$LOG" 2>&1 &
disown

By forcing standard input to /dev/null and using setsid to strip the controlling terminal, Python's sys.stdin.isatty() returns False. This successfully prevents the CLI from attempting to alter the terminal line discipline, and the shell remains fully responsive.

This strongly indicates that the CLI is unnecessarily attempting to hook into and mutate the parent TTY during detached startup, without wrapping those mutations in a safe restoration routine.