Skip to content

docs(home.nix): the laptop leg does not work for the reason this comment gave - #1460

Open
ZacxDev wants to merge 1 commit into
mainfrom
docs/laptop-socket-comment-correction
Open

docs(home.nix): the laptop leg does not work for the reason this comment gave#1460
ZacxDev wants to merge 1 commit into
mainfrom
docs/laptop-socket-comment-correction

Conversation

@ZacxDev

@ZacxDev ZacxDev commented Sep 9, 2026

Copy link
Copy Markdown
Member

docs(home.nix): the laptop leg does not work for the reason this comment gave

MEASURED 2026-09-09, while verifying that the tmux restore stack operates on the
laptop host after #1415/#1376 shipped.

The comment on the tmux-snapshot-push unit's TMUX_TMPDIR pin said:

the LAPTOP leg gets no such guard ... It works because the laptop's socket
is in /tmp. If the laptop ever acquires this host's arrangement it silently
reports zero windows

Both halves are wrong, in opposite directions, and a reader reasoning from
either lands somewhere false.

THE PREMISE IS FALSE. The laptop already HAS this host's arrangement:

/tmp/tmux-1000                        does not exist
/run/user/1000/tmux-1000/default      is the socket
the server's own /proc/<pid>/environ  carries TMUX_TMPDIR=/run/user/1000

THE PREDICTION IS ALSO FALSE. By the old reasoning that leg should now be
reporting zero windows. It is not. Measured over the exact path session-manager
uses — a NON-INTERACTIVE ssh, which sources .zshenv only:

TMUX_TMPDIR=[/run/user/1000]
tmux list-windows -a  ->  29 windows
grep -c TMUX_TMPDIR ~/.zshenv  ->  0

So devrc still does not set it, exactly as the comment says — but the value is
in the ssh session environment anyway. That is the SAME "undeclared runtime
state" this comment already flags two paragraphs earlier for the workbench: a
fact about this boot, not a property of the configuration.

WHAT THE CORRECTION KEEPS. The failure SHAPE is untouched and still worth
knowing: if that leg cannot find the socket it reports zero windows while
session-manager records reachable:true and windows_measured:TRUE, so the
pusher's torn-collection gate cannot catch it. Only an env pin on that side
would. The hazard is MASKED, not absent — the correction says so explicitly, so
nobody reads "it works" as "it is pinned", and says not to restore the /tmp
explanation.

This is the shape claude/RULES.md names: a comment is a claim too, and this one
would have led a maintainer to the wrong conclusion in either direction — either
"the laptop is fine because /tmp" or, on seeing the socket move, "the laptop
must be broken now".

Verified: nix-instantiate --parse nix/home.nix OK; test_tmux_snapshot_push.py
37 passed; the test this comment names,
test_the_unit_gives_tmux_its_SOCKET_directory, 2 passed. Comment-only change —
no evaluated Nix expression is touched.

Co-Authored-By: Claude Opus 5 (1M context) noreply@anthropic.com
Claude-Session: https://claude.ai/code/session_013jdbmhCKa6edhTmiADsziR

…ent gave

MEASURED 2026-09-09, while verifying that the tmux restore stack operates on the
laptop host after #1415/#1376 shipped.

The comment on the tmux-snapshot-push unit's TMUX_TMPDIR pin said:

    the LAPTOP leg gets no such guard ... It works because the laptop's socket
    is in /tmp. If the laptop ever acquires this host's arrangement it silently
    reports zero windows

Both halves are wrong, in opposite directions, and a reader reasoning from
either lands somewhere false.

THE PREMISE IS FALSE. The laptop already HAS this host's arrangement:

    /tmp/tmux-1000                        does not exist
    /run/user/1000/tmux-1000/default      is the socket
    the server's own /proc/<pid>/environ  carries TMUX_TMPDIR=/run/user/1000

THE PREDICTION IS ALSO FALSE. By the old reasoning that leg should now be
reporting zero windows. It is not. Measured over the exact path session-manager
uses — a NON-INTERACTIVE ssh, which sources .zshenv only:

    TMUX_TMPDIR=[/run/user/1000]
    tmux list-windows -a  ->  29 windows
    grep -c TMUX_TMPDIR ~/.zshenv  ->  0

So devrc still does not set it, exactly as the comment says — but the value is
in the ssh session environment anyway. That is the SAME "undeclared runtime
state" this comment already flags two paragraphs earlier for the workbench: a
fact about this boot, not a property of the configuration.

WHAT THE CORRECTION KEEPS. The failure SHAPE is untouched and still worth
knowing: if that leg cannot find the socket it reports zero windows while
session-manager records reachable:true and windows_measured:TRUE, so the
pusher's torn-collection gate cannot catch it. Only an env pin on that side
would. The hazard is MASKED, not absent — the correction says so explicitly, so
nobody reads "it works" as "it is pinned", and says not to restore the /tmp
explanation.

This is the shape claude/RULES.md names: a comment is a claim too, and this one
would have led a maintainer to the wrong conclusion in either direction — either
"the laptop is fine because /tmp" or, on seeing the socket move, "the laptop
must be broken now".

Verified: `nix-instantiate --parse nix/home.nix` OK; test_tmux_snapshot_push.py
37 passed; the test this comment names,
test_the_unit_gives_tmux_its_SOCKET_directory, 2 passed. Comment-only change —
no evaluated Nix expression is touched.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_013jdbmhCKa6edhTmiADsziR
Claude-Session-Id: 097b404c-db17-4472-bd37-dc90cf8fa675
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant