I'm looking for a clean and easy way to share a tmux session with another user on the same machine. I've tried the -S socket-path option, but it requires opening up all permissions of the socket-path before someone else can connect to the session. It works, but it's a little cumbersome. For example:

# Me
$ tmux -S /tmp/pair
$ chmod 777 /tmp/pair

# Another user
$ tmux -S /tmp/pair attach

This works, but both users now share the same tmux configuration (the configuration of the user who initiated the session). Is there a way to allow the two users to use their own tmux config and their own individual tmux key bindings?

For bonus points, ideally, it would also be nice to give read-only access of the tmux session to other users.

  • 33
    I'm too lazy I just use your question as my answer :D
    – phunehehe
    Commented May 23, 2013 at 7:20
  • 1
    Warning: now tmux detach supports -E that replaces the client with an arbitrary shell command. It doesn't matter if the target client runs under a different Unix user. So any user that can access /tmp/pair can run arbitrary code replacing any attached client. The victim may not notice if you re-attach them fast enough: tmux -S /tmp/pair detach -t /dev/victim_tty -E '(malicious shell code) & exec tmux -S /tmp/pair attach' Commented Nov 22, 2019 at 18:27

6 Answers 6


From https://github.com/zolrath/wemux:

wemux enhances tmux to make multi-user terminal multiplexing both easier and more powerful. It allows users to host a wemux server and have clients join in either:

Mirror Mode gives clients (another SSH user on your machine) read-only access to the session, allowing them to see you work, or

Pair Mode allows the client and yourself to work in the same terminal (shared cursor)

Rogue Mode allows the client to pair or work independently in another window (separate cursors) in the same tmux session.

It features multi-server support as well as user listing and notifications when users attach/detach.

It is a shellscript wrapper over tmux - no compiling necessary.

  • 4
    Sadly, in April 2021, this appears to be abandonware. Commented Apr 27, 2021 at 16:21
  • 1
    @JesseAdelman I disagree. The project is not archived, and after setting up port forwarding and an ssh-server, I was able to use this for pair programming in neovim between two different machines. Also nice that only the host needs to install wemux; the client just uses a plain ssh-client to connect. Commented Jul 15, 2021 at 8:24
  • 1
    (I understand the reaction, given it hasn't had an update since 2014 - but evidently this piece of software is simple enough that it just keeps working) I used it on Ubuntu 20. Commented Jul 15, 2021 at 8:26
  • 2
    So, when I say 'abandonware', I mean 27 GitHub Issues not addressed, and 9 Pull Requests uncommented on, and 6 years since the last update. Based on the definition here: en.wikipedia.org/wiki/Abandonware I think this repo's software meets the criteria. :) Cheers. Commented Jul 16, 2021 at 20:45
  • 1
    The github.com/zigdon/wemux fork is active. Commented Dec 8, 2022 at 20:21

I've tried this on Ubuntu but don't see why it wouldn't work on other unix variants.

If both users are members of a common group and the socket-path uses that group both users will be able to attach fine.

Rather than having to change the permissions of the socket-path every time you create one you could create a specific directory for sockets (I used /var/tmux).

First add a group for tmux users

$ addgroup $TMUX_GROUP

Create a directory with the group set to $TMUX_GROUP and use the setgid bit so that files created within the directory automatically have the group set to $TMUX_GROUP.

$ mkdir /var/tmux
$ chgrp $TMUX_GROUP /var/tmux
$ chmod g+ws /var/tmux

Next make sure the users that want to share the session are members of $TMUX_GROUP

$ usermod -aG $TMUX_GROUP user1
$ usermod -aG $TMUX_GROUP user2

Now you create a shared session with

$ tmux -S /var/tmp/shared-session

and attach to it from another account with

$ tmux -S /var/tmp/shared-session attach 
  • 4
    If you have a filesystem that supports ACLs, you don't need to use a group (and in particular you don't need any root intervention). But this doesn't solve the issue of sharing the tmux configuration, does it? Commented Apr 11, 2011 at 20:15
  • 5
    To create shared sesion: tmux -S $TMUX_GROUP/shared-session. To attach to it from another account: tmux -S $TMUX_GROUP/shared-session attach
    – jfs
    Commented Sep 20, 2016 at 17:14
  • 2
    The comment above (by @J.F.Sebastian) should be part of the answer. The setup proposed is ok, but the answer falls short when explaining how to real use it. And for all answers in this page, this answer is the one that better address the problem.
    – DrBeco
    Commented Jul 16, 2017 at 0:07
  • 2
    I was not successful with tmux -S $TMUX_GROUP/shared-session ("lost server) but was successful with tmux -S /var/tmux/shared-session (after logging out and logging back in) Commented May 25, 2021 at 13:30
  • I updated the answer to include jfs suggestion, but corrected per the jason-dufair comment.
    – ntc2
    Commented Jul 20, 2021 at 6:06

This is not exclusive to tmux, but right now it's what I'm using:

You can use script -f /path/to/some/file to write a terminal session to a file. The -f option updates the file while you type.

Someone else (with only read permissions to the file, if you want) can do tail -f to see the file, your terminal session. The -f option makes tail output whatever gets appended.

The combination of the two "sync" the view of a terminal. When used whith tmux, it also has the advantage of avoiding the resize that happens when both users have different resolutions. Another trait is that each user can work on another private window or session.

One potential inconvenience is that some commands (ncurses based for example) may do weird things to the output, escape sequences too (colors). However, I am using this inside tmux, and it seems that tmux fixes those issues. I can see the other user read man pages and use other commands that create buffers, colors are displayed right, etc.

This does not allow to write to each other's terminal though (maybe some other solution could be added for that).

I like to have a window with two panes: one pane running script -f for my peer to see, an another one next to it where I tail -f it's terminal.

It works in ttys as well (and sockets or named pipes may be used too for the file)

  • I like your answer! This is both simple and functional!
    – J-L
    Commented Dec 6, 2018 at 18:32

As far as I know, it is not possible to share sessions with other users in a "clean" way.

Also read-only access is not possible, if the client doesn't use the -r switch.

As another terminal multiplexer screen supports the features you are looking for, sadly also in a cumbersome way... I'm not sure if this is an option for you, but maybe someone other will find this useful.

Solution for screen:

Host a session:

  • SUID bit of screen must be set :-/
  • Open the session with screen -S sessionname
  • ctrla + :multiuser on
  • ctrla + :acladd otherUsername

Join a session:

  • screen -x username/sessionname

You can set permission bits for the user (* for all) with :aclchg or :chacl. # appended will affect windows, ? appended will affect the commands.


  • :aclchg * -wx "#,?" will set the session permissions to read only for all users
  • :aclchg foo +w 2 will give write access for user foo on window 2
  • :aclchg bar +x detach will give the permission for detaching a session to user bar
  • 1
    For what it's worth, I feel that the tmux solution (although slightly more verbose) is actually "cleaner", since it doesn't involve leaving setuid binaries floating around the filesystem.
    – Glyph
    Commented Dec 22, 2010 at 21:01
  • Unfortunately, tmux used this in this way has a security issue: those to whom you give access can easily create new sessions and do things in them that you're not seeing.
    – cjs
    Commented Sep 5, 2011 at 5:37
  • @CurtJ.Sampson How about if the user is forced to run "attach -r", such as through a restricted shell? Commented Dec 29, 2019 at 0:37

There's a very handy tool, it's tmate.

You can use it when you don't have the hand on network, like in a hotel by example.

$ apt-cache show tmate
Package: tmate
Homepage: http://tmate.io/
Description-en: terminal multiplexer with instant terminal sharing
 tmate provides an instant pairing solution, allowing you to share a terminal
 with one or several teammates. Together with a voice call, it's almost like
 pairing in person. The terminal sharing works by using SSH connections to
 backend servers maintained by tmate upstream developers; teammates need to be
 given a randomly-generated token to be able to join a session.
 tmate is a modified version of tmux, and uses the same configurations such as
 keybindings, color schemes etc.

Here is a quick and dirty way of doing it (similar to your example tho updated with a new necessary step):

on the first user account session run:

# create a tmux session using /tmp/tmux_shared_session socket (automatically create it if it doesn't exits already)
tmux -S /tmp/tmux_shared_session

# give group owneship of the tmux socket to the second user
sudo chown $(whoami):SECOND_USER_GROUP_NAME /tmp/tmux_shared_session

# give permissions to the second user group
sudo chmod g+rwx /tmp/tmux_shared_session

# give the second user the tmux authorization to use the current session (note: you need to run this while inside the tmux session)
tmux server-access -a SECOND_USER_NAME

on the second user account session run:

tmux -S /tmp/tmux_shared_session attach

You will need to replace SECOND_USER_NAME and SECOND_USER_GROUP_NAME in the above commands based on your situation.

note: SECOND_USER_GROUP_NAME is basically always identical to SECOND_USER_NAME

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .