The pitch that sold me on Shellular is that a session started on the phone and a session started at the desk are the same session. For Claude Code that is half true today: the transcript is written, but neither resume picker will show it to you.
Start a chat from the app, then go to the machine and look. claude /resume does not list it, and neither does the session list in the VS Code extension. The transcript is there and complete, in the ordinary place:
~/.claude/projects/-home-jk-owly-agent/<session-uuid>.jsonl
One field differs from a session started locally:
| Started from |
entrypoint |
| VS Code |
claude-vscode |
| Shellular app |
sdk-ts |
Both pickers drop that value on purpose. The CLI, in the function that hydrates each candidate for /resume:
if (_.entrypoint === "sdk-cli" || _.entrypoint === "sdk-ts" || _.entrypoint === "sdk-py") return null;
and the VS Code extension does the same behind an includeProgrammaticSessions flag that its editor panel sets to false. There is no setting for it either side.
The intent is legible: SDK sessions are usually automation, and a human's resume list should not fill up with subagent runs. Shellular is caught by it because it drives Claude Code through the same Agent SDK a script would, and the SDK stamps sdk-ts on anything it starts.
It only stamps it as a default, though. From @anthropic-ai/claude-agent-sdk:
if (!env.CLAUDE_CODE_ENTRYPOINT) env.CLAUDE_CODE_ENTRYPOINT = "sdk-ts";
So an inherited value survives, and the fix is for the host to set one when it spawns the adapter. Anything outside sdk-cli, sdk-ts and sdk-py works. cli is the one value to avoid: Claude Code rewrites it to sdk-cli when it runs under the SDK, and it is filtered again.
I have been running with CLAUDE_CODE_ENTRYPOINT=shellular exported into the daemon for a day, and phone-started sessions show up on the desktop the way you would expect. Doing it in the daemon's environment is a workaround for one machine, though. It belongs in the host, so it works for everyone without anyone having to know any of the above.
The pitch that sold me on Shellular is that a session started on the phone and a session started at the desk are the same session. For Claude Code that is half true today: the transcript is written, but neither resume picker will show it to you.
Start a chat from the app, then go to the machine and look.
claude/resumedoes not list it, and neither does the session list in the VS Code extension. The transcript is there and complete, in the ordinary place:One field differs from a session started locally:
entrypointclaude-vscodesdk-tsBoth pickers drop that value on purpose. The CLI, in the function that hydrates each candidate for
/resume:and the VS Code extension does the same behind an
includeProgrammaticSessionsflag that its editor panel sets tofalse. There is no setting for it either side.The intent is legible: SDK sessions are usually automation, and a human's resume list should not fill up with subagent runs. Shellular is caught by it because it drives Claude Code through the same Agent SDK a script would, and the SDK stamps
sdk-tson anything it starts.It only stamps it as a default, though. From
@anthropic-ai/claude-agent-sdk:So an inherited value survives, and the fix is for the host to set one when it spawns the adapter. Anything outside
sdk-cli,sdk-tsandsdk-pyworks.cliis the one value to avoid: Claude Code rewrites it tosdk-cliwhen it runs under the SDK, and it is filtered again.I have been running with
CLAUDE_CODE_ENTRYPOINT=shellularexported into the daemon for a day, and phone-started sessions show up on the desktop the way you would expect. Doing it in the daemon's environment is a workaround for one machine, though. It belongs in the host, so it works for everyone without anyone having to know any of the above.