blog

Claude Code agents fixing bugs you report from your phone, while they refactor

Round two of refactoring Clawdline with Clawdline: four bugs reported from a phone, fixed in parallel, and a review that stopped a fix worse than the bug it fixed.

The first round showed a squad of Claude Code Sessions refactoring Clawdline while the person was out. The second round, on 18 October 2026, had the person back and using the product on their phone while the squad worked.

That changes the job. Bugs arrive in the middle of a refactor, from a screenshot, with one sentence of description. The squad’s work did not slow down, and nothing it fixed reached the phone on one Session’s word alone.

A screenshot became a to-do, and the to-do became a Session

The person circled a problem on a phone screenshot and sent it. Clawdline attached it to the coordinating Session as a to-do. The coordinator read the code, wrote what it had verified into a brief and handed the brief to a new Session.

A phone screen adding a Session to-do: the text says a booking row is not indented under its trip, and the attached image is a phone screenshot with the problem circled in red.
A bug report from the phone, as a Session to-do. Demo project; the circle is drawn on the screenshot.

That happened four times in one afternoon:

What the person saw What was wrong
A converted Plan filled with bogus steps Its analysis was parsed as a task list
A child Session sometimes not nested under its root The task list was re-read only every four minutes
The Schedules page calling an online Mac offline A reconnecting page reported its own connection as the Mac’s
“No Session available” when one was The dialog drew an empty list before the list had loaded

Each fix began with a test that failed on the old code. The refactor kept running beside them, because each Session worked in its own private checkout.

The review that stopped a fix worse than the bug

The first fix for the nesting bug passed its tests. Then an independent reviewer tried to break it, and did. When a root’s tab closed and a new Session reused its terminal number, the child was nested under the wrong Session.

A child in the wrong place is worse than a child in no place. So the fix did not land. A second Session took the review, its probe tests and the branch, fixed all three findings, and a second reviewer checked each one again. After it shipped, the coordinator watched the daemon’s log for ten minutes with children running: no child lost its parent.

That pattern held all day. Reviewers wrote their own breaking changes, and each time one survived, a test was added before merging. The person did not have to read a diff.

Old answers were recorded before the old code was deleted

The biggest change replaced about 2,600 lines of hand-written decoding with code generated from one table. Every action on the phone goes through it.

Before deleting anything, a Session recorded what the old code answered for 142,267 inputs. The new code had to give identical answers. Then a reviewer ran both versions through the real message bridge and compared 303,581 lines of output. Every byte matched.

A test written after the old code is gone can only describe the new code. Recording first keeps the old behaviour as the yardstick.

The phone was diagnosed without asking for screenshots

The person also reported that the phone could not connect directly to the Mac. Asking for network details from a phone is slow and unreliable, so the squad built a way to see for itself.

Every direct-connection attempt now leaves one line on each side, linked by one id: what kinds of network candidates each side offered, how many filters removed, when the connection checks started, and the step where the attempt stopped. No address, port or credential is written. A security reviewer tried fifteen hostile candidate shapes to make one leak.

The first lines arrived within a minute of deployment. They already showed one lead: the Mac was discarding its own IPv6 candidates while the phone offered its own. The design that follows goes to the person as choices, not as a change made for them.

Work can come from another Session, but scope comes from the person

Another Session, investigating the same connection problem, sent the coordinator a Board item and later asked it to add a second fix. Both messages said the person had agreed.

The coordinator still asked the person directly, both times, with a short multiple-choice prompt on the phone. A message from another agent is information, not permission. The answer took seconds, and the scope on the Board is the one the person chose.

A Session conversation on a phone with a message from another Session, labelled with its name, asking this Session to take a Board item and saying the owner agreed. The same Session waiting for the person, asking whether to take the forwarded item now, with three one-tap answers.
Left: another Session asks for the work. Right: the person is asked before it is taken. Demo project.

The squad also hit something it had not caused: another Session’s commit turned the main branch red, and the push was refused. The coordinator reran the failing test locally, then reran only the failed CI job, and pushed once it was green.

What the second round adds

The first round showed that a squad can do the work. This one showed it can take interruptions. New bugs from a phone became tracked work in parallel with the refactor. Reviews caught what tests missed. Behaviour was pinned before code was removed. And the person spent their time choosing, not supervising.

The Board guide covers items, steps and to-dos; the workflows guide covers dispatch, review and landing; and why “done” has four meanings explains why no Session marks its own work landed.