The released CLI cannot share a long session. path share on a 2.3 MB derived document dies at the transport's fixed 30-second ceiling:
$ path share --harness claude --session <id> --project <dir> --repo dev/pathstash
Cached claude session → claude-path-claude-code-640bb070 (2280121 bytes)
Error: upload to dev/pathstash failed: request timed out after 30s — try again, or shrink the upload
The advice in that message is not actionable. "Try again" re-uploads the same bytes into the same ceiling, and "shrink the upload" is not something the user controls — the document size is whatever the session was. A day of agent work produces several MB, and the whole point of share is to publish exactly that.
Why this is filed rather than fixed
It is already fixed, on a branch that never reached main. #248 (feat(share): make the upload timeout settable, and raise the default) adds --timeout <SECS>, defaults it to 300, and threads PATH_HTTP_TIMEOUT_SECS through. That PR was merged into a personal staging branch instead of main, so it has been sitting unreleased.
Same session, same server, binary built from the branch:
$ path share ... --timeout 300
Uploaded claude session → dev/pathstash/graphs/7e92de1b-… (unlisted, 2347095 bytes)
So the fix is real and verified; it just needs to land. Filing this so the gap is visible in the issue tracker rather than only in a branch listing, and so there is something to close when it does.
Impact
Anyone on the released 0.18.0 hits a hard ceiling on how long a session can be before it becomes unshareable, with an error that suggests the failure is theirs to work around. The plugin's /path:share runs the same code path, so it fails the same way.
Suggested resolution
Cherry-pick #248's commit onto a fresh branch off main and PR it. Worth pairing with a look at whether 300s is right for a slow link, or whether the upload should stream/chunk rather than go up in one request — the flag makes the ceiling movable but does not remove it.
The released CLI cannot share a long session.
path shareon a 2.3 MB derived document dies at the transport's fixed 30-second ceiling:The advice in that message is not actionable. "Try again" re-uploads the same bytes into the same ceiling, and "shrink the upload" is not something the user controls — the document size is whatever the session was. A day of agent work produces several MB, and the whole point of
shareis to publish exactly that.Why this is filed rather than fixed
It is already fixed, on a branch that never reached main. #248 (
feat(share): make the upload timeout settable, and raise the default) adds--timeout <SECS>, defaults it to 300, and threadsPATH_HTTP_TIMEOUT_SECSthrough. That PR was merged into a personal staging branch instead ofmain, so it has been sitting unreleased.Same session, same server, binary built from the branch:
So the fix is real and verified; it just needs to land. Filing this so the gap is visible in the issue tracker rather than only in a branch listing, and so there is something to close when it does.
Impact
Anyone on the released 0.18.0 hits a hard ceiling on how long a session can be before it becomes unshareable, with an error that suggests the failure is theirs to work around. The plugin's
/path:shareruns the same code path, so it fails the same way.Suggested resolution
Cherry-pick #248's commit onto a fresh branch off
mainand PR it. Worth pairing with a look at whether 300s is right for a slow link, or whether the upload should stream/chunk rather than go up in one request — the flag makes the ceiling movable but does not remove it.