Skip to content

feat(sessions): pick up a session Caprock did not start - #22

Merged
dspv merged 1 commit into
masterfrom
feat/continue-a-session-here
Sep 2, 2026
Merged

feat(sessions): pick up a session Caprock did not start#22
dspv merged 1 commit into
masterfrom
feat/continue-a-session-here

Conversation

@dspv

@dspv dspv commented Sep 2, 2026

Copy link
Copy Markdown
Owner

"я не знаю как мне перехватить сессию… или например если я при завершении сессии получаю номер этой сессии чтобы я мог где-то ввести и продолжить её"

Both halves of that, and the second one turns out to solve the first.

Why it could not be done directly

Rule 7 — Caprock never types into a process it did not launch — is concrete rather than principled: two writers on one PTY interleave characters and ruin both terminals. So a session started in your own terminal was readable here and nothing else. Stats, timeline, cost, and no way to act on any of it.

What actually works

claude --resume starts a second process on the same conversation, history read from disk. Nothing is taken from the terminal that already has one, and the new process is one Caprock started — so it is typeable like any other, with stats, timeline and terminal all live.

Two shapes, because the situation has two

Still running → branch. --fork-session and a new id, because two live processes sharing one id would write a single transcript between them and each end up holding half the other's turns.

Ended → continue under the same id. Nothing to collide with.

Checked against the real binary, not assumed

$ claude --resume <id> --session-id <other> -p hi
Error: --session-id can only be used with --continue or --resume
if --fork-session is also specified.

Which is the same distinction from the other side. Reading claude --help cost nothing next to finding this out from a user — a lesson from earlier today, applied.

Verified end to end

Branched this very conversation into Caprock and watched its own history appear in the web terminal. The copy came up OWNED with pause/resume/kill live, while the original carried on untouched.

The command is offered for copying too — somebody who lives in tmux does not want a second place to type.

https://claude.ai/code/session_01DR8fggA2LRHcjNWUsqtDcF

Rule 7 says Caprock never types into a process it did not launch, and the
reason is concrete rather than principled: two writers on one PTY
interleave characters and ruin both terminals. So a session started in
somebody's own terminal was readable here and nothing else — the stats,
the timeline, the cost, and no way to act on any of it.

`claude --resume` is the way through, and it does not break the rule. It
starts a *second* process on the same conversation, with the history read
from disk. Nothing is taken away from the terminal that already has one,
and the new process is one Caprock started, so it is typeable like any
other — stats, timeline and terminal all live.

Two shapes, because the situation has two.

While the original is still running the copy branches: --fork-session and
a new id. Two live processes sharing one id would write a single
transcript between them and each end up holding half the other's turns.
Once the original has ended there is nothing to collide with, so it
simply continues under the same id.

Both flag combinations were checked against the real binary rather than
assumed. `--session-id` alongside `--resume` is refused outright unless
--fork-session is present, which is the same distinction the other way
round, and finding that out from `claude --help` cost nothing compared to
finding it out from a user.

Verified end to end: branched this very conversation into Caprock, saw
its own history in the terminal, and the copy came up OWNED with
pause/resume/kill live.

The command is offered for copying too. Somebody who lives in tmux does
not want a second place to type.

Claude-Session: https://claude.ai/code/session_01DR8fggA2LRHcjNWUsqtDcF
@dspv
dspv merged commit 3fcdd11 into master Sep 2, 2026
9 checks passed
@dspv
dspv deleted the feat/continue-a-session-here branch September 2, 2026 14:45
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