I shipped an open-source PR from my phone

The project

Zero is a programming language for AI agents, built by Vercel Labs. The idea: instead of wiring agents together with Python glue code and hoping the orchestration holds, you describe agent behavior in a language designed for it. Active development, a small contributor community, and the kind of early-stage repo where a focused PR actually moves the needle.

I contributed to it from my phone on a Sunday afternoon. No laptop, no IDE — just the Claude.ai mobile app and a remote Claude Code session running on my machine at home.

Starting a remote session

Claude Code has a remote sessionsfeature — you start a session on your machine and get a shareable link. Open that link on your phone and you're driving the same running agent: your home directory, your git config, your SSH keys, full tool access. Nothing is proxied through a cloud sandbox; it's literally your machine.

Start Claude normally, then run the remote control slash command:

claude
> /remote-control

(You can also use the shorthand /rc.) That prints a URL. Open it on your phone. You're in.

Finding the right issue

I asked Claude to clone the Zero repo and scan the open issues for something self-contained — a bug or small feature where the scope was clear and the fix wouldn't require deep context on the language runtime. That's the first-contributor cheat code: find something labeled good first issue, or anything where the fix is obviously bounded. You learn the project's conventions without getting lost in domain logic, and reviewers are patient because the issue was designed for it.

Claude read the issue list, we picked a target, agreed on an approach in the chat thread. No laptop touched.

The actual work

Once we had a target, the flow was the same as any local Claude Code session. Claude read the relevant files, made the change, showed me the diff. I reviewed it in the chat window on my phone — which is fine for diffs; the font is small but readable — and approved or redirected from there.

The part that still feels a bit surreal: I'm on the couch, typing with my thumbs, and a machine across the house is editing source files in a programming language compiler repo, running checks, and staging commits. The latency between "looks good" and "commit staged" is under a second.

When the change was ready, Claude opened the PR with gh pr create, wrote the description against the issue, and handed me the URL to review.

The PR

Result: vercel-labs/zero #78. Small, scoped, useful. The kind of contribution that gets merged without a lot of back-and-forth — which is exactly what you want when you're new to a codebase and new to the domain.

What this unlocks

Open-source contribution used to require a block of free time at a desk. Clone the repo, set up the dev environment, understand enough context to not make it worse. The activation energy was high enough that most contributions never happened — not for lack of motivation, but because the friction compounded with every step.

Remote sessions kill that friction. You don't need a fresh environment. You don't need a laptop. If you have twenty minutes and a phone, you have enough to ship something real.

Same logic extends further: reviewing a PR while commuting, unblocking a deploy when you're away from your desk, checking on a long-running agent task. The session is persistent. You just need to open the link.

Practical notes

• Start the session before you leave. Run claude then /rc on a machine that stays on. A desktop works better than a laptop that might sleep mid-session.
• Keep prompts short. Mobile typing is slower, which turns out to be good discipline — it forces you to be direct. Short, clear prompts work better over a remote session anyway.
• Read every diff.The phone browser renders diffs fine. Pinch-to-zoom on anything subtle. Don't approve changes you haven't actually read just because the screen is small. If the project has automated tests, lean on them — a passing CI run gives you a second opinion that doesn't depend on how carefully you can read on a 6-inch screen.
• Match issue complexity to the context.Your first PR to any codebase should be something you can fully understand on a small screen. Save the architectural changes for when you're at a desk with full context.