Install ccsesh, a CLI that fuzzy-searches and resumes Claude Code sessions
across every project on this machine. Repo: https://github.com/yedhink/ccsesh

Context: Claude Code's built-in `claude --resume` only lists sessions for
the current directory. ccsesh reads the global session store at
~/.claude/projects/ and surfaces every session in one fzf picker.

Execute the steps below in order. Surface errors verbatim. Steps 1 and 6
ASK the user questions — you MUST ask them and wait, do not pick on
their behalf.

1. Ask the user where to clone the ccsesh repo.
   This location is PERSISTENT — future `git pull` runs there to fetch
   updates, and the installer creates a symlink
   ~/.local/bin/ccsesh -> <clone-path>/bin/ccsesh that points into it.
   Ask this question verbatim and WAIT for the user's answer:

   > "Where should I clone the ccsesh repo?
   >   (a) Home directory: ~/ccsesh
   >   (b) /tmp/ccsesh  (throwaway — /tmp is typically wiped on reboot,
   >       so pick this only if you're just trying ccsesh out; future
   >       `git pull` updates will break after the tmp directory is
   >       cleared)
   >   (c) Somewhere else (tell me the path)"

   Do NOT guess a location like ~/dev/ccsesh without asking. If the user
   picks (c), confirm the expanded path back to them before cloning.

2. Verify prerequisites.
   - `claude --version` must succeed. If it does not, ccsesh is useless
     without Claude Code — stop; do not try to install it.
   - Note whether `git`, `jq`, and `fzf` are on PATH. Do not install
     jq/fzf yourself; the installer handles those.

3. Clone the repo.
   - `git clone git@github.com:yedhink/ccsesh.git <chosen-path>`
     (the repo is private, so SSH-over-port-22 is the only working clone
     URL; HTTPS cloning will prompt for credentials and fail under an
     AI agent's non-interactive shell)
   - If the path already exists as a ccsesh checkout, run
     `git -C <chosen-path> pull` instead. If it exists and is NOT a
     ccsesh checkout, stop and ask.

4. Run the installer.
   - `cd <chosen-path> && ./install.sh`
   The installer:
     * detects OS (macOS/Linux — aborts on anything else)
     * installs jq and fzf via brew / apt / dnf / pacman if missing
     * symlinks ~/.local/bin/ccsesh -> <repo>/bin/ccsesh (idempotent)
     * copies <repo>/config.example.jsonc to ~/.config/ccsesh/
     * prints PATH advice for the detected shell if ~/.local/bin is
       not already on PATH
   Relay installer output. If it exits non-zero, stop — don't retry blindly.

5. Verify the basic install.
   - `which ccsesh` resolves to ~/.local/bin/ccsesh (or wherever the
     installer reported). If not, apply the PATH-setup line from step 4
     and tell the user which rc file to add it to.
   - `ccsesh --version` prints `ccsesh <semver>`.
   - `ccsesh --list | head -3` prints up to 3 TSV rows. Zero rows is fine
     and just means the user has no Claude sessions yet (or
     ~/.claude/projects/ is empty). Note it, don't treat it as an error.

6. Ask the user about the Enter action.
   By default, pressing Enter on a session replaces the current shell
   with `claude --resume <sid>` — so ccsesh exits when you hit Enter.
   Many users prefer opening the resume in a new tab/window so ccsesh
   stays up for the next pick. Ask the user this question verbatim and
   WAIT for their answer:

   > "Pressing Enter on a session — what should happen?
   >   (a) Replace my current shell with claude --resume (the default)
   >   (b) Open the session in a new tab of my current terminal
   >   (c) Open the session in a new tmux window (only if you use tmux)
   >   (d) Run a custom command I'll describe
   >   (e) I'll configure it later myself"

   If the user chose (a) or (e): skip to step 8. No config needed.

7. Configure the chosen Enter action.

   For (b) "new tab in current terminal":
     Detect which terminal the user is running right now:
       - $WEZTERM_PANE is set           → WezTerm
       - $TERM_PROGRAM == "ghostty"     → Ghostty (needs 1.3+)
       - $TERM_PROGRAM == "iTerm.app"   → iTerm2
       - otherwise                      → ask the user which terminal
     Copy the matching helper from the repo:
       cp <repo>/examples/wezterm-new-tab ~/.local/bin/
       # or ghostty-new-tab, or iterm2-new-tab
       chmod +x ~/.local/bin/<helper>
     For terminals without a ready-made helper: point the user at the
     inline recipe in ~/.config/ccsesh/config.example.jsonc and warn
     them about the PATH-strip gotcha (tell them to resolve `claude`
     to an absolute path if the inline form fails).

   For (c) "new tmux window": no helper script needed; use the inline
   recipe below.

   For (d) "custom command": ask the user for the script path OR the
   exact shell command. Explain the contract: the script receives sid
   as $1 and cwd as $2; or the command may use {sid} / {cwd} as
   placeholders (both auto shell-escaped by ccsesh).

   Then write ~/.config/ccsesh/config.json with exactly ONE of the
   following (pick the one matching the user's choice):

     # (b) WezTerm
     { "enter": { "command": "~/.local/bin/wezterm-new-tab {sid} {cwd}" } }

     # (b) Ghostty
     { "enter": { "command": "~/.local/bin/ghostty-new-tab {sid} {cwd}" } }

     # (b) iTerm2
     { "enter": { "command": "~/.local/bin/iterm2-new-tab {sid} {cwd}" } }

     # (c) tmux
     { "enter": { "command": "tmux new-window -c {cwd} -- claude --resume {sid}" } }

     # (d) user's script
     { "enter": { "command": "<user-path-or-command> {sid} {cwd}" } }

   Use mkdir -p first:
     mkdir -p ~/.config/ccsesh
     cat > ~/.config/ccsesh/config.json <<'JSON'
     <the chosen block on one line>
     JSON

   Verify the expansion looks right. No env var setup is required —
   ccsesh reads ~/.config/ccsesh/config.json by default:
     bash -c 'source <repo>/lib/util.sh
              source <repo>/lib/ui.sh
              _ccsesh_ui_enter_expand "test-sid" "/tmp"'
   This should print the command that ccsesh will exec on Enter.

   Do NOT tell the user to add any ccsesh env var to their shell rc
   files. There isn't one. The config file at the path above is all
   ccsesh needs.

8. Report back. Include:
   - install location
   - `which ccsesh` and `ccsesh --version` output
   - number of sessions ccsesh can see (`ccsesh --list | wc -l`)
   - any PATH step the user still needs to apply manually
   - which Enter-action recipe (if any) was configured

Rules:
- Do NOT edit the user's shell rc file automatically. Print the line and
  tell the user which file to add it to.
- Do NOT use sudo. The installer avoids it by design.
- Do NOT switch branches, pick a fork, or pin a tag. Use the default
  branch of yedhink/ccsesh.
- Do NOT skip step 1's or step 6's question. Both require the user's
  answer; do not pick on their behalf or assume a default location.
- Do NOT proceed past a failing step. Surface the error and ask.

Troubleshooting cheatsheet:
- `command not found: brew` on macOS → direct the user to https://brew.sh
  and stop; the installer can't complete without it.
- `permission denied` creating the symlink → ensure ~/.local/bin is
  user-writable; do not sudo.
- `ccsesh: missing jq` / `missing fzf` at runtime → re-run ./install.sh;
  the user may have declined the package install earlier.
- `No conversation found with session ID` after resume → ccsesh cd's
  into the original project dir; if that dir was deleted, ccsesh prints
  a clear error without launching claude.
- `bash: line 0: exec: claude: not found` when using a custom tab-opener
  → the terminal is exec'ing the command via a PATH-stripped login
  shell. The ready-made helpers in <repo>/examples/ already resolve
  `claude`'s absolute path to sidestep this; custom scripts need to do
  the same.