Use C-Space tmux prefix in remote sessions; document GitHub stacked PRs for agents - #28
Conversation
In nested tmux (local C-b outer, remote inner), the remote prefix becomes C-Space so hotkeys need no doubled C-b. Detection keys on SSH_CONNECTION, which mosh sessions inherit from the bootstrap ssh. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Global agent instructions for the gh-stack workflow: when PRs would chain (A->main, B->A), use native stacks — covers commands, merge and rebase semantics, and preview limits. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
|
Important Review skippedAuto reviews are disabled on this repository. Please check the settings in the CodeRabbit UI or the ⚙️ Run configurationConfiguration used: Path: .coderabbit.yaml Review profile: CHILL Plan: Pro Run ID: You can disable this status message by setting the Use the checkbox below for a quick retry:
📝 WalkthroughWalkthroughThe changes document the ChangesStacked pull request guidance
Remote tmux prefix configuration
Estimated code review effort: 2 (Simple) | ~10 minutes Poem
🚥 Pre-merge checks | ✅ 5✅ Passed checks (5 passed)
✨ Finishing Touches🧪 Generate unit tests (beta)
Comment |
Match scriptlancer: reviews on request only, no auto-review per PR. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 5
🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
Inline comments:
In `@claude-md/.claude/CLAUDE.md`:
- Line 129: Update the Tooling entry for the official gh-stack extension to list
only the prerequisites supported by its README: GitHub CLI v2.0+ and no stated
Git minimum. Remove the unsupported GitHub CLI ≥ 2.90.0 and Git ≥ 2.20
requirements.
- Line 155: Update the “Adopting an existing chain” guidance to distinguish
local adoption from remote-only conversion: direct users needing local gh stack
rebase or gh stack sync support to use gh stack init with the chain branches,
and reserve gh stack link for remotely linking an existing chain.
- Line 127: Update the stacked pull request rule to use GitHub native stacks
only when gh-stack is available and all branches are in the same repository.
Revise the guidance around the manual workflow to document using manual
base-branch management when gh-stack is unavailable or repositories differ,
while preserving separate PRs against main for independent changes.
- Line 150: Update the stack merge documentation near the existing bottom-to-top
merge guidance to distinguish direct merges from merge-queue behavior: direct
merges include the selected PR and every PR below it, while queued stacks may
land in separate groups. Document cleanup separately, including that interactive
gh stack sync prompts before pruning and gh stack sync --prune prunes
automatically.
In `@tmux/.tmux.conf`:
- Around line 3-7: Update the tmux configuration around the SSH-based prefix
selection so local and SSH clients use separate tmux sockets, rather than
relying on if-shell evaluation during server startup. Ensure each socket applies
the correct prefix for its client type and preserves the documented
prefix-plus-d detach workflow, and add lifecycle coverage verifying behavior
when clients attach to an existing server.
🪄 Autofix (Beta)
Fix all unresolved CodeRabbit comments on this PR:
- Push a commit to this branch (recommended)
- Create a new PR with the fixes
ℹ️ Review info
⚙️ Run configuration
Configuration used: Path: .coderabbit.yaml
Review profile: CHILL
Plan: Pro
Run ID: 22cdaf0a-1815-4c12-9a14-20fb0a046ecc
📒 Files selected for processing (2)
claude-md/.claude/CLAUDE.mdtmux/.tmux.conf
|
|
||
| ## GitHub stacked PRs (use the native feature) | ||
|
|
||
| **The rule:** whenever work forms a chain of dependent branches — branch A targeting `main`, branch B targeting A, C targeting B — **always use GitHub's native stacked pull requests**, never ad-hoc chained PRs or manual base-branch juggling. The trigger is simple: if you're about to open a PR whose base is another open PR's branch, make it a native stack instead. Independent changes are not a stack — keep those as separate PRs against `main`. |
There was a problem hiding this comment.
🎯 Functional Correctness | 🟠 Major | ⚡ Quick win
🧩 Analysis chain
🏁 Script executed:
sed -n '115,165p' claude-md/.claude/CLAUDE.mdRepository: Vilos92/dotfiles
Length of output: 5678
🌐 Web query:
GitHub gh-stack native stacked pull requests private preview same repository cross-fork support
💡 Result:
As of August 4, 2026, GitHub's native stacked pull request functionality is in public preview [1][2][3]. The feature allows users to chain pull requests within the same repository, where each pull request targets the branch of the one below it [1][4]. Key details regarding the current status and limitations of this feature: 1. Repository Requirement: Stacked pull requests must reside entirely within the same repository [1][3]. Official GitHub documentation explicitly states that cross-fork stacks are not supported [1][3]. 2. Public Preview Status: The feature transitioned from private preview to public preview on July 30, 2026 [2][5]. 3. Tooling Support: Management of these stacks is primarily handled through the gh stack GitHub CLI extension [1][3][6]. The feature is also integrated into the GitHub website, GitHub Mobile, and is accessible via the API, allowing users to navigate and merge stacked pull requests directly within the platform [3][4]. Because the requirement for all branches to be in the same repository is a stated limitation in the official documentation, cross-fork support remains unavailable at this time [1][3].
Citations:
- 1: https://docs.github.com/en/pull-requests/reference/stacked-pull-requests
- 2: https://github.blog/changelog/2026-07-30-stacked-pull-requests-are-now-in-public-preview/
- 3: https://docs.github.com/en/pull-requests/get-started/about-stacked-prs
- 4: https://docs.github.com/en/pull-requests/tutorials/stack-code-changes-in-pull-requests
- 5: https://byteiota.com/github-stacked-prs-private-beta-waitlist-required/
- 6: https://github.com/github/gh-stack
Make native stacks conditional on support.
If gh-stack is unavailable or the branches span repositories, use the documented manual fallback. Native stacked PRs currently require all branches to be in the same repository. Update the rule and lines 153–157 accordingly.
🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
In `@claude-md/.claude/CLAUDE.md` at line 127, Update the stacked pull request
rule to use GitHub native stacks only when gh-stack is available and all
branches are in the same repository. Revise the guidance around the manual
workflow to document using manual base-branch management when gh-stack is
unavailable or repositories differ, while preserving separate PRs against main
for independent changes.
|
|
||
| **The rule:** whenever work forms a chain of dependent branches — branch A targeting `main`, branch B targeting A, C targeting B — **always use GitHub's native stacked pull requests**, never ad-hoc chained PRs or manual base-branch juggling. The trigger is simple: if you're about to open a PR whose base is another open PR's branch, make it a native stack instead. Independent changes are not a stack — keep those as separate PRs against `main`. | ||
|
|
||
| **Tooling:** the official `gh-stack` extension (needs GitHub CLI ≥ 2.90.0, Git ≥ 2.20): |
There was a problem hiding this comment.
🎯 Functional Correctness | 🟡 Minor | ⚡ Quick win
🧩 Analysis chain
🏁 Script executed:
#!/usr/bin/env bash
set -euo pipefail
gh --version
git --version
curl -fsSL https://raw.githubusercontent.com/github/gh-stack/main/README.md |
sed -n '/## Installation/,/## AI agent integration/p'Repository: Vilos92/dotfiles
Length of output: 409
Use supported gh-stack prerequisites.
The official README requires GitHub CLI v2.0+ and specifies no Git minimum. Remove GitHub CLI ≥ 2.90.0 and Git ≥ 2.20, or cite a source for those requirements.
🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
In `@claude-md/.claude/CLAUDE.md` at line 129, Update the Tooling entry for the
official gh-stack extension to list only the prerequisites supported by its
README: GitHub CLI v2.0+ and no stated Git minimum. Remove the unsupported
GitHub CLI ≥ 2.90.0 and Git ≥ 2.20 requirements.
|
|
||
| **Semantics to respect (don't fight them manually):** | ||
|
|
||
| - Stacks merge **bottom-to-top**. Merging a mid-stack PR also merges everything below it in one operation. The PRs above stay open, **auto-retarget** to the trunk, and GitHub **automatically rebases** the next unmerged PR server-side — never hand-edit the base branch of a stacked PR. Your **local** branches don't follow along, though: run `gh stack sync` after a merge to pull down the rewritten branches and prune merged ones. |
There was a problem hiding this comment.
🎯 Functional Correctness | 🟡 Minor | ⚡ Quick win
🧩 Analysis chain
🏁 Script executed:
#!/bin/bash
set -eu
file=$(git ls-files | awk '$0=="claude-md/.claude/CLAUDE.md"{print; exit}')
[ -n "$file" ]
sed -n '130,165p' "$file"
printf '\n--- stack-related references ---\n'
rg -n -i 'gh stack|merge.queue|merge queue|retarget|prune|auto.*rebase|partial merge' claude-md .github 2>/dev/null | head -200Repository: Vilos92/dotfiles
Length of output: 5461
🌐 Web query:
site:github.com/github/gh-stack FAQ partial merge lowest unmerged PR merge queue gh stack sync --prune
💡 Result:
In the context of the gh-stack CLI, these terms and commands relate to managing stacked pull requests and CI optimization: Lowest Unmerged PR: When optimizing Continuous Integration (CI) for a stack of PRs, you can use the stack metadata (such as position, where 1 is the bottom) to gate workflow steps [1]. A common practice is to run intensive CI checks only on the lowest unmerged PR in a stack, as it serves as the base for the PRs above it [1]. Partial Merge: Merging a stack of PRs is designed as an atomic, all-or-nothing operation: if any PR in the stack cannot be merged (e.g., due to failing branch protection rules), none of the PRs will be merged [2][3]. If the base branch uses a merge queue, the stack is added to the queue together; while they may land in separate groups as the queue processes them, they remain part of a linked stack operation [2][3]. Merge Queue: When a repository uses a merge queue, gh stack merge adds the entire stack to the queue rather than merging directly [2]. In this scenario, the merge queue determines the merge method, and any merge method flags provided to gh stack merge are ignored with a warning [2][3]. gh stack sync --prune: The gh stack sync command is used to fetch the latest changes, rebase your local stack, and reconcile the remote stack state on GitHub [4]. The --prune flag (or using it in an interactive terminal) automatically deletes local branches for PRs that have already been merged into the base branch, helping to keep your local environment clean [4][5][6].
Citations:
- 1: Docs Content Updates github/gh-stack#185
- 2: https://github.com/github/gh-stack/blob/main/README.md
- 3: https://github.com/github/gh-stack/blob/main/skills/gh-stack/SKILL.md
- 4: https://github.com/github/gh-stack
- 5: https://github.com/github/gh-stack/releases/tag/v0.0.4
- 6: [bug] local branch not deleted on restack github/gh-stack#23
🏁 Script executed:
#!/bin/bash
set -eu
base=https://raw.githubusercontent.com/github/gh-stack/main
for path in README.md skills/gh-stack/SKILL.md faq.md; do
echo "--- $path ---"
curl -fsSL "$base/$path" | rg -n -i -C 4 'partial|atomic|all.or.nothing|merge queue|queue|eject|retarget|lowest unmerged|sync|prune'
doneRepository: Vilos92/dotfiles
Length of output: 11389
🌐 Web query:
site:github.github.com/gh-stack/faq "lowest unmerged" "merge queue" "sync --prune"
💡 Result:
There is no known command or technical documentation for "lowest unmerged merge queue sync --prune." The provided search results do not contain references to a tool, command, or workflow using these specific terms together. It is possible that this query refers to a custom internal tool, a non-standard alias, or an incorrect command syntax.
Citations:
🏁 Script executed:
#!/bin/bash
set -eu
for url in \
https://github.github.com/gh-stack/faq/ \
https://github.github.com/gh-stack/faq \
https://raw.githubusercontent.com/github/gh-stack/main/docs/faq.md \
https://raw.githubusercontent.com/github/gh-stack/main/FAQ.md
do
echo "--- $url ---"
if body=$(curl -fsSL "$url" 2>/dev/null); then
printf '%s\n' "$body" | rg -n -i -C 5 'retarget|lowest|unmerged|base branch|merge queue|descendant|stacked PR'
else
echo "unavailable"
fi
doneRepository: Vilos92/dotfiles
Length of output: 202
🌐 Web query:
GitHub gh-stack partial merge retarget lowest unmerged pull request higher PRs remain chained
💡 Result:
In the GitHub Stacked Pull Requests workflow, you cannot merge a mid-stack pull request in isolation [1][2]. Merging a pull request in a stack always requires that the pull request, along with all pull requests below it, form a contiguous group starting from the lowest unmerged pull request [1]. When you perform a merge on a pull request within a stack: 1. The selected pull request and all unmerged pull requests below it are merged into the base branch together as a single operation [1][2]. 2. The pull requests above the merged group remain open [2]. 3. These higher, unmerged pull requests are automatically rebased to target the stack's base branch (e.g., main) directly [1][2]. This effectively moves them to the bottom of the stack, preparing them for review and subsequent merging [1]. If a merge is attempted and fails partway through the stack (for instance, due to a conflict), the successfully merged pull requests remain on the base branch, while the failed pull request and any pull requests above it stay open [3]. Once the issue is resolved on the failed pull request, you can retry the merge to continue landing the remainder of the stack [3]. The GitHub CLI (gh-stack) manages these dependencies and cascading operations, ensuring that the linear history required for stacking is maintained [4][2]. If you choose to merge a mid-stack pull request, the system treats it as a merge of that specific PR and everything beneath it [1][5].
Citations:
- 1: https://docs.github.com/en/pull-requests/how-tos/merge-and-close-pull-requests/merging-stacked-pull-requests
- 2: https://docs.github.com/en/pull-requests/get-started/about-stacked-prs
- 3: https://docs.github.com/en/enterprise-cloud@latest/pull-requests/how-tos/merge-and-close-pull-requests/troubleshooting-stacked-pull-requests
- 4: https://docs.github.com/en/pull-requests/how-tos/create-pull-requests/managing-stacked-pull-requests
- 5: https://docs.github.com/en/pull-requests/reference/stacked-prs-cli-commands
🏁 Script executed:
#!/bin/bash
set -eu
urls=(
"https://docs.github.com/en/pull-requests/how-tos/merge-and-close-pull-requests/merging-stacked-pull-requests"
"https://docs.github.com/en/pull-requests/get-started/about-stacked-prs"
"https://docs.github.com/en/pull-requests/reference/stacked-prs-cli-commands"
)
for url in "${urls[@]}"; do
echo "--- $url ---"
curl -fsSL "$url" |
sed 's/<[^>]*>/ /g; s/"/"/g; s/&`#39`;/'"'"'/g; s/&/\&/g' |
tr -s '[:space:]' ' ' |
fold -w 180 |
rg -i -C 2 'retarget|target.*base|higher|above|merge queue|atomic|all.or.nothing|sync|prune'
doneRepository: Vilos92/dotfiles
Length of output: 310
🌐 Web query:
site:docs.github.com/en/pull-requests "higher" "automatically rebased" "stacked pull requests"
💡 Result:
Automatically rebased stacked pull requests refer to the process of maintaining a linear commit history across a chain of dependent pull requests, which is a requirement for merging them [1][2]. In a stacked workflow, where pull requests are built on top of one another, the history must remain linear—meaning each branch must contain the tip of the branch below it [1][3]. Automatic rebasing is handled in two primary ways: 1. Server-side automatic rebasing: When a stack is not linear (e.g., because the trunk moved ahead or changes were pushed to a lower branch), GitHub provides a Rebase stack button in the merge box [4][2]. Selecting this triggers a server-side cascading rebase that updates the entire stack, rebasing it onto the latest trunk and ensuring every unmerged branch is rebased on top of its base branch [2]. After the rebase, CI checks are automatically re-triggered [2]. 2. Local cascading rebase: Users can maintain their stacks locally using the gh stack extension in the GitHub CLI [5][2]. The command gh stack rebase performs a cascading rebase, automatically fetching the latest changes and ensuring each branch in the stack is rebased onto its parent branch [2][3]. This command also automatically enables git rerere to assist in remembering conflict resolutions across rebases [3]. Additionally, when a pull request at the bottom of a stack is merged, the remaining branches in the stack are automatically rebased or re-targeted so that the next pull request points directly to the stack's base branch (e.g., main), effectively moving it to the bottom of the stack for review and merging [5][4][6].
Citations:
- 1: https://docs.github.com/en/pull-requests/reference/stacked-pull-requests
- 2: https://docs.github.com/en/pull-requests/how-tos/create-pull-requests/managing-stacked-pull-requests
- 3: https://docs.github.com/en/pull-requests/reference/stacked-prs-cli-commands
- 4: https://docs.github.com/en/pull-requests/how-tos/merge-and-close-pull-requests/merging-stacked-pull-requests
- 5: https://docs.github.com/en/pull-requests/get-started/about-stacked-prs
- 6: https://docs.github.com/en/pull-requests/how-tos/merge-and-close-pull-requests/optimizing-ci-for-stacked-pull-requests
🏁 Script executed:
#!/bin/bash
set -eu
python3 - <<'PY'
from html.parser import HTMLParser
from urllib.request import Request, urlopen
urls = [
"https://docs.github.com/en/pull-requests/how-tos/merge-and-close-pull-requests/merging-stacked-pull-requests",
"https://docs.github.com/en/pull-requests/get-started/about-stacked-prs",
"https://docs.github.com/en/pull-requests/reference/stacked-prs-cli-commands",
]
class Text(HTMLParser):
def __init__(self):
super().__init__()
self.parts = []
def handle_data(self, data):
self.parts.append(data)
for url in urls:
print(f"--- {url} ---")
parser = Text()
data = urlopen(Request(url, headers={"User-Agent": "Mozilla/5.0"}), timeout=20).read().decode("utf-8", "replace")
parser.feed(data)
text = " ".join(" ".join(parser.parts).split())
terms = ("retarget", "target", "higher", "above", "merge queue", "atomic", "all-or-nothing", "prune", "sync")
words = text.split()
for i, word in enumerate(words):
if any(term in " ".join(words[max(0, i-3):i+4]).lower() for term in terms):
print(" ".join(words[max(0, i-35):i+36]))
PYRepository: Vilos92/dotfiles
Length of output: 2558
🌐 Web query:
site:docs.github.com/en/pull-requests/how-tos/merge-and-close-pull-requests/merging-stacked-pull-requests "next pull request" "base branch"
💡 Result:
In a pull request, the base branch is the destination branch into which your proposed changes will be merged once the pull request is accepted [1]. It represents the target or trunk branch of your work [1]. In contrast, the head branch (or compare branch) contains the commits you have authored and are proposing to merge into that base branch. When working with stacked pull requests, the base branch for a specific pull request in the stack may be the branch of the pull request directly below it in the sequence [1]. Once a pull request in a stack is merged, the remaining unmerged pull requests are typically rebased so that their new base branch becomes the original stack base, such as main [1]. If you need to change the base branch of an existing open pull request, platforms like GitHub typically provide an option to edit the base branch directly within the pull request interface.
Citations:
Document merge-queue and cleanup behavior separately.
Direct merges are all-or-nothing for the selected PR and all PRs below it. Merge-queue stacks enter the queue together but may land in separate groups. State that gh stack sync prompts before pruning in interactive terminals, while gh stack sync --prune prunes automatically.
🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
In `@claude-md/.claude/CLAUDE.md` at line 150, Update the stack merge
documentation near the existing bottom-to-top merge guidance to distinguish
direct merges from merge-queue behavior: direct merges include the selected PR
and every PR below it, while queued stacks may land in separate groups. Document
cleanup separately, including that interactive gh stack sync prompts before
pruning and gh stack sync --prune prunes automatically.
| - Branch protection and CI requirements come from the **bottom PR's base branch** and apply to every layer. | ||
| - Public-preview limits: all branches must live in the **same repository** (no cross-fork stacks), and programmatic merges must go through `gh stack merge` / the new merge API — not the classic merge endpoint. | ||
|
|
||
| **Adopting an existing chain:** if a traditional stack already exists (PRs manually chained by base branch), convert it with `gh stack link` instead of continuing to manage it by hand. |
There was a problem hiding this comment.
🎯 Functional Correctness | 🟡 Minor | ⚡ Quick win
🧩 Analysis chain
🏁 Script executed:
rg -n -C 3 'gh stack (link|init|rebase|sync)|Adopting an existing chain' claude-md . 2>/dev/null | head -200Repository: Vilos92/dotfiles
Length of output: 6157
🌐 Web query:
github gh-stack documentation "gh stack link" "gh stack init"
💡 Result:
The gh stack extension for the GitHub CLI (gh) enables users to create and manage stacked pull requests—a series of dependent pull requests that allow large changes to be broken down into smaller, independently reviewable layers [1][2]. The extension is installed via: gh extension install github/gh-stack Key Commands gh stack init This command initializes a new stack in the current repository [3][4]. It sets up local tracking and prepares the first branch [5][2]. If run without arguments, it enters an interactive mode, prompting for a branch name and offering to use the current branch as the first layer [2][4]. You can specify branch names directly (e.g., gh stack init branch1 branch2) or override the trunk/base branch (which defaults to the repository's default branch) using the --base flag [4]. gh stack link This command is used to link existing branches or pull requests into a stack on GitHub without creating local tracking state [6][7]. It is specifically designed for workflows where stacked branches are managed by external tools (such as Jujutsu, Sapling, or git-town) [6][7]. Usage involves listing branches or pull request numbers from bottom to top (e.g., gh stack link branch1 branch2) [6][7]. If the first argument is an existing stack number, new branches or pull requests are appended to the top of that stack [7]. Documentation Authoritative documentation for these commands and the broader stacked pull requests workflow is available on GitHub's official documentation site and the extension's repository [3][1][2]: GitHub Docs: Stacked pull requests CLI commands GitHub repository: github/gh-stack
Citations:
- 1: https://docs.github.com/en/pull-requests/how-tos/stacked-pull-requests
- 2: https://github.com/github/gh-stack
- 3: https://docs.github.com/en/pull-requests/reference/stacked-prs-cli-commands
- 4: https://github.com/github/gh-stack/blob/main/README.md
- 5: https://docs.github.com/en/pull-requests/get-started/stacked-prs-quickstart
- 6: https://docs.github.com/en/pull-requests/reference/use-other-tools-with-stacked-pull-requests
- 7: https://github.com/github/gh-stack/blob/main/skills/gh-stack/SKILL.md
Document local adoption separately from remote linking.
If users need local gh stack rebase or gh stack sync support, use gh stack init <bottom> <next> .... Use gh stack link for remote-only conversion.
🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
In `@claude-md/.claude/CLAUDE.md` at line 155, Update the “Adopting an existing
chain” guidance to distinguish local adoption from remote-only conversion:
direct users needing local gh stack rebase or gh stack sync support to use gh
stack init with the chain branches, and reserve gh stack link for remotely
linking an existing chain.
| if-shell 'test -n "$SSH_CONNECTION" || test -n "$SSH_TTY"' { | ||
| unbind C-b | ||
| set -g prefix C-Space | ||
| bind C-Space send-prefix | ||
| } |
There was a problem hiding this comment.
🎯 Functional Correctness | 🟠 Major | 🏗️ Heavy lift
🧩 Analysis chain
🏁 Script executed:
#!/usr/bin/env bash
set -euo pipefail
socket="coderabbit-prefix-review-$$"
trap 'tmux -L "$socket" kill-server >/dev/null 2>&1 || true' EXIT
env -u SSH_CONNECTION -u SSH_TTY \
tmux -L "$socket" -f tmux/.tmux.conf \
new-session -d -s persistent
before="$(tmux -L "$socket" show-options -gv prefix)"
SSH_CONNECTION='client 1 2 3' \
tmux -L "$socket" new-session -d -s ssh-client
after="$(tmux -L "$socket" show-options -gv prefix)"
test "$before" = C-b
test "$after" = C-SpaceRepository: Vilos92/dotfiles
Length of output: 197
🏁 Script executed:
#!/usr/bin/env bash
set -euo pipefail
printf '%s\n' '--- tmux/.tmux.conf ---'
cat -n tmux/.tmux.conf
printf '%s\n' '--- relevant AGENTS.md text ---'
if [ -f AGENTS.md ]; then
sed -n '75,95p' AGENTS.md
else
printf '%s\n' 'AGENTS.md not found at repository root'
fi
printf '%s\n' '--- tmux references ---'
rg -n -i 'tmux|C-Space|C-b|SSH_CONNECTION|SSH_TTY' --glob '!node_modules' --glob '!dist' --glob '!build' .Repository: Vilos92/dotfiles
Length of output: 5630
🌐 Web query:
tmux man page server reads configuration when server starts new client attaches environment SSH_CONNECTION
💡 Result:
The tmux server reads its configuration files only when it first starts [1]. By default, it loads /etc/tmux.conf if present, followed by the user configuration file at ~/.tmux.conf or the location specified by $XDG_CONFIG_HOME/tmux/tmux.conf [2][3][1]. Regarding the interaction between tmux and environment variables like SSH_CONNECTION when a client attaches, the following points apply: 1. Server Lifecycle: The tmux server is a long-running process [4]. Once started, it does not re-read configuration files or refresh its global environment unless explicitly instructed to do so (e.g., via the source-file command) [5][1]. 2. update-environment Option: tmux maintains a session environment that is merged with the global environment when new windows are created [6][7]. To ensure that specific environment variables—such as SSH_CONNECTION or SSH_AUTH_SOCK—are updated in the session when a client attaches to an existing server, those variables must be included in the tmux option update-environment [7][8]. 3. Client Attachment: When update-environment is configured, tmux automatically updates the variables listed in that option within the session environment whenever a new client attaches [7]. This allows the new client's environment values to be propagated to the session [9][7]. 4. Existing Processes: Note that updating environment variables in the tmux session environment affects only new windows or panes created after the update [7]. Existing shell processes already running within the tmux session will typically retain their original, stale environment variables unless the user manually updates them, for example by using tmux show-environment to export the new values into the current shell [9][7].
Citations:
- 1: https://github.com/tmux/tmux/blob/d7f59ecc/tmux.1
- 2: https://man.openbsd.org/OpenBSD-current/man1/tmux
- 3: https://man.archlinux.org/man/tmux.1
- 4: https://github.com/tmux/tmux/blob/master/tmux.1
- 5: https://deepwiki.com/tmux/tmux/5.4-configuration-loading
- 6: https://aj.codes/blog/be-careful-using-tmux-and-environment-variables/
- 7: https://stackoverflow.com/questions/9901657/how-to-change-an-environment-variable-and-apply-to-all-windows-in-a-tmux-session
- 8: https://manselmi.github.io/notes/tmux-env-var-sync/
- 9: https://unix.stackexchange.com/questions/508863/how-to-pass-an-environment-variable-from-the-currently-attached-client-into-a-tm
Use separate tmux sockets for local and SSH clients. if-shell runs when the tmux server reads its configuration, not when a client attaches. An existing server therefore keeps the prefix selected by its startup environment, which can break the documented prefix + d detach workflow. Add lifecycle coverage for this case.
🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
In `@tmux/.tmux.conf` around lines 3 - 7, Update the tmux configuration around the
SSH-based prefix selection so local and SSH clients use separate tmux sockets,
rather than relying on if-shell evaluation during server startup. Ensure each
socket applies the correct prefix for its client type and preserves the
documented prefix-plus-d detach workflow, and add lifecycle coverage verifying
behavior when clients attach to an existing server.
Per the gh-stack README: gh CLI v2.0+ (no git minimum), gh stack link is remote-only linking with no local tracking, and sync prompts before pruning unless --prune is passed. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
1 participant
Summary
Two focused changes:
tmux:
C-Spaceprefix in ssh/mosh sessionsC-Space(C-bis unbound); local machines keepC-b.C-bdance in nested tmux: outer local tmux answersC-b, inner remote tmux answersC-Space.SSH_CONNECTION(withSSH_TTYas backup) — verified against the mosh 1.4.0 source and a livemoshsession to the Mac Mini that mosh sessions inheritSSH_CONNECTIONfrom the bootstrap ssh connection.C-bunbound remotely,C-b C-bnow delivers a literalC-bto remote programs (e.g. vim page-up).Stowed CLAUDE.md: native GitHub stacked PRs
gh-stackextension.gh stackcommands, merge semantics (bottom-to-top, auto-retarget + server-side rebase of the next PR after a merge,gh stack syncto realign local branches), the cases that do not auto-rebase (trunk drift, amended lower layers → explicit Rebase stack /gh stack rebase), and public-preview limits.Testing
C-SpacewithSSH_CONNECTIONset andC-bwithout.gregs-mac-miniconfirmedSSH_CONNECTIONis present.🤖 Generated with Claude Code
Summary by CodeRabbit
New Features
C-Spaceas the prefix key and forwarding prefix commands.Documentation