Where's My Work
A read-only screen that answers "what actually happened to my changes?" — it reads your project's copy of the repository and groups every branch into plain-language buckets (landed, waiting on review, turned down, stranded), so a reader who does not use git can still see whether finished work reached the shared repo or is sitting on this machine unasked.
A read-only screen that answers one question: what actually happened to my changes?
What it is
Every session that builds something leaves work behind on your own computer: a branch, with commits on it. Some of that work has already reached the shared repository everyone works from, some is still waiting for someone to accept it, and some was never offered to anyone at all.
Where's My Work reads your project's copy of the repository and GitHub, then files every branch it finds into one of six buckets written in plain words — Landed, Waiting on review, Turned down, Stranded, Couldn't check, Housekeeping. You never see the words "ahead", "behind", "merged" or "closed" as the headline; the status a branch is filed under reflects what is really in the shared repo, not what a pull request claims.
The whole screen is read-only. It changes nothing — not your files, not the shared repo, not GitHub. It exists so you can tell, at a glance, whether finished work is safe.
Where to find it
- Settings → the toolbar icon. Where's My Work ships off by default. Turn it on via the
wheresMyWorkEnabledsetting, and a Where's My Work icon appears in the app's toolbar; click it to open the screen. Click the X to close it. - Inside the screen:
- A project selector at the top left — the screen reads one project at a time. It opens on the project you already have open, or the first one, so it is never a dead end.
- A Refresh button — re-reads the repository and re-checks GitHub.
- Pull-request links on each branch card, opening on GitHub in your browser.
How it behaves
The headline and the counts. At the top, one sentence states where things stand, followed by four count tiles. Which four depends on whether GitHub could be reached: normally Waiting on review · Turned down · Stranded · Landed, and when GitHub is unreachable Couldn't check · Landed · Waiting on review · Turned down.
Three reference rows below the counts, comparing your machine against the shared repository:
- Shared repo — the newest change in the shared repository, marked the source of truth.
- Your computer — the newest change here, with how many are not shared yet. If some of those are merge bookkeeping rather than changes of yours, a note underneath says so.
- Working on — the branch you are on right now.
The six buckets. Every branch is filed into exactly one. A bucket only appears when it has something in it, and carries a one-line explanation of what it means:
- Waiting on review — Offered to the shared repo. Someone else has to accept it.
- Turned down — The pull request was closed without being merged.
- Stranded — Finished work on this machine that nobody has been asked to take. This is the bucket worth acting on: the work exists and is safe, but no one has been asked to accept it.
- Couldn't check — These have unshared work, but GitHub could not be reached — so they may be waiting on review rather than stranded. Shown only when GitHub was unreachable, so a network problem is never reported as stranded work.
- Landed — Everything on these is already in the shared repo.
- Housekeeping — Safety copies and scratch branches — not your work, kept out of the counts above.
Each branch card shows the branch name, its bucket as a coloured pill, the last change's description and date, how many changes are not shared yet and how many are behind, and a pill per pull request (open, merged, or closed) linking to GitHub — or no pull request when none was raised. A card can also carry a lighter note when the shared repo is more forgiving than GitHub reads:
- the work is in the shared repo even though the pull request reads closed — nothing was lost;
- the pull request reached the shared repo and was then taken back out — it is not live today;
- some of the changes look like they already reached the shared repo under different ids.
Two honest limits, both stated on the screen. If the shared repo could not be reached, a notice says so and the last state this machine knows is shown instead. If GitHub could not be reached at all, its own notice appears. And when a project has more branches than the screen checks in one pass, a notice reports how many were not checked for pull requests — they are still listed, just without their GitHub detail.
For agents
- Screen entry:
src/renderer/src/features/wheres-my-work/WheresMyWorkView.tsx; mounted as thewheres-my-workview insrc/renderer/src/app/AppRoutes.tsxand a member ofTOP_LEVEL_VIEWSinsrc/renderer/src/app/top-level-views.ts. - Reads over one IPC channel,
WHERES_MY_WORK_GET({ projectId }), backed bysrc/main/services/wheres-my-work/. It performs no writes. - Gated by the shipped AppSettings boolean
wheresMyWorkEnabled(src/shared/types/settings/agent-tools-settings.ts), defaultfalse.
Related
- session-land-status-strip.md — the same "where did my work land?" question, answered for one session, shown at the foot of that session's conversation.
- pm-my-work.md — a different screen despite the similar name: a cross-board personal task list from your Mission Control boards, not a view of git branches.
Last verified 2026-09-28