manaflow-ai/cmux

Summary A cmux-tui client whose controlling terminal (pty) has disappeared does not exit. Its input thread spins at 100% of one CPU core indefinitely, and the process ignores SIGTERM. In my case it ran unnoticed for ~3 days (~24 h of CPU time) and kept the machine's fans at full speed. Environment Linux x86_64 (Ubuntu-based, kernel 7.0.0-38-generic), X11 npm package cmux 0.13.4 (cmux-tui-linux-x64); cmux --version prints cmux 0.1.0 (ec4cbd4fdd16526d5653d7a1f76496ef785f2a2a; ghostty abd40f6e472d57f2d4bb182004bb5f3fac8df961) Client was the process that auto-started the headless session server (--headless --session main), i.e. the headless server was its child. What I observed Client cmux-tui (non-headless), started 3 days earlier, TTY column ?. ls -l /proc/<pid>/fd/0 /proc/<pid>/fd/1 -> both /dev/pts/1 (deleted). So the terminal it was launched in went away at some point (I don't know exactly how it was closed). top -H -p <pid>: one thread named input at ~100% CPU (state R), all other

Bug: initial-command SSH surfaces silently fall back to Mac-local image paths Related: #1660 (SSH image paste). This is a narrowed, reproducible missing-TTY-metadata case, not a request to add a new upload mechanism. cmux version 0.64.25 macOS version 27.0.1 Mac chip Apple Silicon (arm64) Installation method Native /Applications/cmux.app; exact original install method unknown (no Homebrew Caskroom entry). Can you reproduce this on cmux NIGHTLY? I could not test NIGHTLY: this is an interactive user's machine; changing their installed app was out of scope. Which part of cmux is this about? input / remote / terminal shell integration Environment cmux v0.64.25, macOS client, Linux OpenSSH server. Reproduced with a plain remote shell, a remote PTY-attached coding-agent TUI, and that TUI viewed through a terminal multiplexer. No multiplexer-specific change is necessary. Minimal anonymized repro Create a cmux terminal surface using initial_command: "ssh -t example-host bash --noprofile --nor

Bug description In dark appearance, a workspace color's row fill gets brighter as the configured color gets darker. Picking a near-black custom color produces a lighter fill than a mid-tone one, so there's no way to get a dark, low-contrast row fill with indicatorStyle: "solidFill". Measured on screen (solidFill, sidebar tint #000000 at 0.88, center of the row fill): Configured color HSB brightness Rendered fill #0E151B 0.11 #53759A #67879E 0.62 #536C82 The darker input renders lighter, and more saturated. The cause is brightenedForDarkAppearance in Sources/WorkspaceTabColorSettings.swift: let boostedBrightness = min(1, max(brightness, 0.62) + ((1 - brightness) * 0.28)) The (1 - brightness) * 0.28 term is added on top of the 0.62 floor, so brightness 0.11 maps to 0.87 while 0.62 maps to 0.73. The output is lowest at an input of 0.62 and rises on both sides. displayNSColor applies this to every color whenever colorScheme == .dark, and there's no setting to opt out. Expected

cmux version 0.64.25-nightly.3701906366 macOS version 26.6.2 Mac chip Apple Silicon (M1/M2/M3/M4) Installation method Direct download (DMG) Can you reproduce this on cmux NIGHTLY? Yes, it still reproduces on NIGHTLY Bug description Since #16523, a file pasted or dropped onto a remote pane (cmux ssh-tmux mirror) is uploaded to ~/.cache/cmux/paste//cmux-paste-.. Making it private is a good change. But the pane now receives ~/.cache/cmux/paste/…/cmux-paste-….png, with the leading ~ backslash-escaped. A shell treats ~ as a literal ~, so the path doesn't resolve, and Claude Code no longer recognises the paste as an image. Before #16523, the /tmp/cmux-drop-….png path was attached as [Image #1]. Expected behavior The pane receives a path that resolves on the remote host: the absolute path (e.g. /home/u/.cache/cmux/paste/…/cmux-paste-….png), so agent CLIs attach it as an image the way they did with /tmp. The upload's maintenance script already runs on the host and could report $HOME.

Feature request Please add an option to always ask for confirmation before closing a workspace, even when cmux does not detect a running foreground process or other state that currently triggers the close warning. Why I accidentally closed a long-lived iOS migrations workspace containing many panes and ongoing project context. These workspaces are durable project environments that I keep around over time; whether a process happens to be running at the moment is not a good measure of whether the workspace is safe to close. Rebuilding the layout and recovering sessions took extra work, and I do not want an idle-looking workspace to disappear from one mistaken close action. Requested behavior Add a preference to always confirm workspace closure, independent of process/activity detection. Apply it consistently to workspace close actions such as the sidebar close action and the close-workspace shortcut. Keep the existing conditional behavior available for users who prefer it. A per-worksp