Interactive capability approval corrupts terminal output when stdin is a TTY

[wswsmao]

What happened?

When running nono interactively with --capability-elevation, the capability approval prompt can corrupt the terminal layout when stdin, stdout, and stderr are connected to a TTY.

The output lines become misaligned or shifted around the approval prompt. The process then waits for an approval decision, but the prompt is difficult to read or interact with.

Redirecting stdin from /dev/null avoids the PTY path and makes the prompt render normally.

What did you expect to happen?

The capability approval prompt should be rendered at a stable terminal position.

After entering y or n, the request should be granted or denied normally, and the terminal layout should remain usable.

Waiting for the user to answer Grant access? [y/N] is expected behavior. The issue is the corrupted terminal output and interaction experience.

Steps to reproduce

1. Run the following command from an interactive terminal:

   "$NONO_BIN" run --allow-cwd --capability-elevation -- cat /etc/hostname

2. Wait until a capability approval request is displayed.

3. Observe that the output around the prompt may be shifted or interleaved.

4. Compare it with the following command:

   "$NONO_BIN" run --allow-cwd --capability-elevation -- cat /etc/hostname </dev/null

5. The second command does not use the same interactive PTY path, and the prompt is rendered normally.

Relevant output or logs

Capabilities:
────────────────────────────────────────────────────
  r   /mock/code/sandbox/nono/scratch/audit-demo/work (dir)
     + 43 system/group paths (-v to show)
 net  outbound allowed
────────────────────────────────────────────────────

 kernel  Landlock V3
        degraded: TCP filtering, IoctlDev, Scoping (upgrade kernel for full support)
 Applying sandbox...

[nono] The sandboxed process is requesting additional access:
[nono]   Path:   /proc/3389245/cmdline
[nono]   Access: read-only
[nono]   Reason: Sandbox intercepted file operation (seccomp-notify)
[nono]
[nono] Grant access? [y/N]


Without `</dev/null`, the output may be displayed with incorrect line positioning and the process appears to remain stuck until manually terminated.

With `</dev/null`, the approval prompt is displayed normally.

nono version

0.70.0

Operating system

Linux

OS version / distro

OpenCloudOS Stream 23

Kernel version (Linux only)

6.6.119-49.20.tl4.x86_64

Profile (if relevant)

Additional context

No response

[nogent-nolabs-ai]

🛡️ nogent issue triage

Assessment: needs-code-change

Suggested resolution: Modify the TTY raw mode or terminal state handling in crates/nono-cli/src/tool-sandbox/terminal_approval.rs or related interactive drawing utilities to properly configure and restore terminal settings when prompting the user.

Notes for maintainers: The rendering/input issue when stdin/stdout/stderr are connected to a TTY suggests that the interactive prompt logic in crates/nono-cli does not correctly coordinate raw terminal mode state or stdout/stderr buffering during concurrent execution of the child process. A code fix is required to isolate and restore terminal layouts during interactive elevation prompts.

_{Automated triage suggestion. Not a maintainer decision.}

[aguerlain-lr]

Looks related to the issues I'm seeing running the claude code agent view. When nono attempts to request approval, it seems to fight with agent view or claude itself and there is just garbled text that is either very hard or impossible to interact with.

[lukehinds]

gah, I thought we were fixed from #1254 , @aguerlain-lr or @wswsmao are you able to screenshot what you see, even a gif or video? it would be useful to know which terminals you are using as well.

[aguerlain-lr]

@lukehinds I will go create a dedicated nono profile that has a trivially triggerable 'approval' policy and then trigger it to reproduce. fwiw my issue is the same symptom but I use a very different stack and it's perhaps more appropriate recorded as a separate issue. (MacOS + nono wrapping Claude Code's agent view, but Claude code agent view uses PTY to switch between displaying the daemons for the sessions it manages).

[aguerlain-lr]

@lukehinds — here's what I see (macOS). Video:

Screen.Recording.2026-07-29.at.12.58.17.PM.mov

Terminal: iTerm2 on macOS 15.7.3 (Darwin 24.6.0), shell zsh. The sandboxed program is Claude Code's own full-screen TUI (Node/Ink), which additionally spawns detached PTY workers (claude daemon run, bg-pty-host, bg-spare). I don't think it's iTerm-specific — it's raw-mode + alt-screen vs. line-oriented writes, so it should show in any emulator.

Why #1254 doesn't fix this one: #1254 pauses the supervised PTY relay (raw→cooked) around the capability-elevation prompt, and assumes a single attached interactive terminal. This is a different path and topology:

• Different prompt: it's a command_policies approve-bucket prompt (approval_backends.tty, type: terminal), not capability-elevation. - Different topology: the gated exec happens below a detached worker with its own PTY, while the foreground TUI owns the terminal the human sees. There's no single relay to pause — nono knows the offending pid but not which terminal is in front of the user.

What's in the video: it fires with no user action. Claude polls git at startup (git --no-optional-locks status --short) to draw its status indicator; with a git subcommand in an approve bucket that startup probe alone raises the prompt — note Caller: session and the --no-optional-locks status --short argv, i.e. Claude's own top-level process, before any user/agent command. The prompt then staircases into the TUI (each [nono] field indented further right, reason string overwriting column 0, Grant access? [y/N] stranded at the bottom) and Ctrl-C won't cleanly exit.

Env: nono 0.69.0

Minimal repro: profile with interactive: true + a git command policy routing status to an approve bucket on the tty backend, launched under a git repo:
nono run --allow-cwd --profile -- claude
(kubectl→approve delete or docker→approve build are equivalent manual triggers; the prompt fires at exec-intercept so no cluster/daemon needed.) Full minimal profile + a proposed fix (non-TTY / auto-detected approval backend) I can drop in a follow-up if useful.

--

If you want me to open a separate issue and/or a PR, happy to do so and delete this comment as unrelated/distracting.

[lukehinds]

huh, that's strange - capability expansion should be linux gated and not available on macos, as it requires seccomp - will take a look.

edit:
forget the above, i see its command_policies based.

[lukehinds]

So for the first report from @wswsmao , I don't know much about OpenCloudOS Stream 23 , but I just tested on nono 0.71 with Fedora 34 and I am not hitting any issues:

[lukehinds]

Note my /etc/hostname is empty, which explains now output of content