Classic confinement request: pmux

store-requests classic-confinement
1

Classing confinement request for pmux

  • name: pmux

  • description: Transparent tmux proxy that enables secure, end-to-end encrypted remote terminal access from a mobile device via WebRTC.

  • snapcraft: Snap built via GoReleaser. Config in the snapcrafts section of .goreleaser.yaml in the upstream repository (no standalone snapcraft.yaml).

  • upstream: GitHub - ShiftinBits/pmux-agent: Agent and CLI package for pmux · GitHub

  • upstream-relation: Author and maintainer. Published by ShiftinBits Inc.

  • supported-category: terminal emulator / terminal tool (same category as alacritty, kitty, wezterm)

  • reasoning: pmux is a transparent proxy for the host’s tmux binary. It forwards all user-supplied commands to tmux -L pmux via syscall.Exec. This requires:

    • Host binary execution: Must locate and exec the system-installed tmux binary, which lives outside the snap’s filesystem.
    • PTY allocation: Allocates pseudo-terminals (/dev/ptmx) to bridge remote clients into live tmux panes.
    • User environment access: tmux spawns the user’s shell ($SHELL), reads dotfiles (~/.bashrc, ~/.zshrc), and accesses arbitrary paths referenced in terminal sessions.
    • OS keychain: Stores Ed25519 identity keys via the system keyring (go-keyring), with encrypted file fallback.

    These are the same requirements that place terminal emulators in the classic confinement category. No combination of strict confinement interfaces can satisfy arbitrary command execution through the host’s terminal subsystem. The snap is a single statically-compiled Go binary with no stage packages.

I understand that strict confinement is generally preferred over classic.

I’ve tried the existing interfaces to make the snap to work under strict confinement.

2

This request has been added to the queue for review by the @reviewers team.

3

Additional details regarding the entire system can be found at https://docs.pmux.io

4

Hi @bobbyshiftinbits

It is plausible that there are technical reasons why pmux needs classic to work properly in all scenarios, but please note that classic confinement is a sensitive matter and it is reserved for mature, well-known applications published by mature, well-known entities. As of today, I believe that pmux doesn’t meet this criteria because of the following reasons:

  • The project seems to be very fresh, according to the upstream repository

  • The projects seems to have little/none community around according to upstream repository (contributors, issues, PRs, etc.)

  • I could not find evidences that the project has a strong enough user base currently

Thus, considering these factors, I think pmux should not get classic confinement as of now.

5

Hi, thanks for the review and the candid feedback.

I want to address both the technical requirement and the traction concerns separately.

On technical necessity: pmux-agent is a CLI daemon that bridges a local tmux session to a mobile device over WebRTC. To function, it must access tmux sockets, spawn and attach to tmux processes on the host, interact with pseudo-terminals, and read shell/SSH configuration from the user’s home directory. These are not edge cases, they are the entire purpose of the tool. Strict confinement’s filesystem and process sandboxing would make pmux non-functional, not degraded. I’m happy to walk through specific requirements if that would be helpful.

On project maturity: I hear you, and I acknowledge the project is early-stage. That said, I want to flag a few things:

  • The CLI, agent, signaling server, and protocol are all MIT-licensed and published across multiple repositories. This isn’t a prototype, it’s a shipping product with an Android app in closed testing and iOS pending Apple review.

    • If you’d entertain the idea, I’ll gladly add you to the list of test Android users on Google Play so that you can test the system end-to-end.

  • Distribution via homebrew is already live, but snap is a critical channel for reaching Linux users who expect to install CLI tools through their system package manager.

I understand that classic confinement is reserved for established tools, but I’d respectfully note the circular challenge: snap is one of the primary distribution platforms for this audience, and it’s difficult to build that user base without being available where users look.

I can provide more identifying information about ShiftinBits Inc. such as articles of incorporation, DUNS numbers, etc. if that would have any bearing on the decision. Otherwise I’d welcome a time-boxed reconsideration, happy to revisit traction metrics in a few months if that’s the preferred path forward.