You have explained the same concern three ways in a GitHub pull request. The author has replied with another code excerpt. Both of you are writing carefully, yet the disputed path is getting less clear with every comment.
That is a good moment to stop adding prose. A code review screen share can turn the stuck part into a short conversation: open the exact code, trace the behavior, agree on the next change, and end the room. The written review still matters. It just no longer has to carry a conversation that needs a shared view and immediate questions.
Know when the thread has stopped helping
Stay in comments when the feedback is precise and self-contained: rename this value, cover this branch, remove this duplication. The author can make the change without needing to reconstruct your mental model.
Move to a live code review when the disagreement depends on a sequence that is hard to hold in text. Perhaps the reviewer is reasoning from the API boundary while the author is reasoning from the UI. Perhaps “this state cannot happen” means different things to each person. Perhaps one question keeps producing larger code snippets but no shared understanding.
A useful trigger is simple: if your next comment would mostly restate the last one, ask for a five-minute walkthrough of the disputed path. Five minutes is a scope, not a stopwatch promise. It says, “Let’s resolve this one knot,” not, “Let’s turn the pull request into a meeting.”
Run a live code review around one question
A focused walkthrough begins before anyone shares a screen. Name the question in one sentence:
Can we trace how an expired token reaches this retry branch?
That sentence gives the session an exit condition. Once both people can answer it, the live portion is done.
Have the person who can reproduce the disputed behavior host the room. Before sharing, open the branch, relevant test, and input that triggers the path. Select only the editor window or browser tab needed for the walkthrough. Keep notifications, unrelated repositories, credentials, and personal tabs outside the shared surface.
Walk through the behavior in the order the program encounters it:
- Start at the input or event that matters.
- Follow the path into the disputed code.
- Pause where the two interpretations diverge.
- Show the test, log, or visible behavior that would distinguish them.
- State the agreed change before leaving the room.
The reviewer should ask short questions rather than narrate a replacement implementation. “What calls this?” and “What happens when this value is absent?” keep the host on the disputed path. Linkside is view-only: the host can point or draw on the shared screen. Guests can watch, talk, and chat, but cannot annotate or control the host’s keyboard or mouse. When both people need to edit, switch to a collaborative coding setup; our guide to pair programming over a link draws that line more fully.
Put the result back in the pull request
Treat the conversation as working space, not the final review record. Before the session ends, identify what should return to the pull request:
- the decision you reached;
- the reason that changed or confirmed the approach;
- any required code or test change;
- anything still unresolved.
Keep that update short. “Walked through the retry path together; the expired-token case can reach this branch, so we’ll add the missing test and keep the guard” is more useful than a transcript of the conversation.
Without a pull-request update, the written record may jump from the last objection to the next commit without explaining the decision. Add the decision and its reason before treating the thread as resolved. If a review needs a recording, automatic transcript, durable meeting room, or formal attendance record, choose a tool designed to retain those artifacts. The broader screen-sharing tool guide starts with those requirements.
Use Linkside for the quick handoff
We built Linkside for this narrow “show me” moment. The host creates a temporary room in the browser, sends the link in the conversation already in progress, and starts sharing. There is nothing to install, and the guest joins without an account or signup wall. Both people can use microphone audio while the host stays in control of the shared computer.
Underneath, Linkside tries to send the screen and audio directly between browsers. If the direct path cannot be established, it can fall back to an encrypted TURN relay. Desktop Chrome and Edge are the recommended host experience.
There is no recording or transcript to manage afterward. When the session ends, the room closes and its temporary state moves toward deletion. That lifecycle is covered in why Linkside rooms are ephemeral.
Temporary does not mean invisible to the systems that connect the call. Linkside’s signaling service can observe that a room exists, roughly when a guest joins, and how long the session lasts. If a TURN relay is needed, it routes encrypted packets and can observe that network traffic, but not the screen or audio inside those packets. We do not pair that operational data with an account identity or retain it long-term.
Those choices make Linkside a fit for a trusted reviewer seeing code that only needs to be visible during the conversation. They do not decide what is safe to show. The guest sees the surface the host selects, including any secret visible on it. Choose the narrowest useful window, close unrelated material, and send the room link only to the intended reviewer.
End when the knot is untangled
Do not keep going merely because the room is open. Once the disputed path is clear, say the decision aloud, stop sharing, and write the outcome in the pull request. Any new issue can return to normal comments or get its own focused walkthrough.
A focused live review has two boundaries: one disputed question before sharing and one written pull-request update afterward. When the next thread starts circling, create a Linkside room, share the relevant window, and close it when the question is answered.