Auto-lander dashboard — waiting on your approval (part 3)

What it is

This is part 3 of the Auto-lander dashboard page. That page covers the view itself — the live status, the queue and the land history — and its part 2 carries the refusal catalogue and what happens after a land. This page is the branches the lander stops and asks you about, and the holds it puts in place to keep already-landed work from being thrown away.

Where to find it

The same view as the rest of the page: the Auto-lander view in the Dev Pipeline panel, reached from the Runs screen. Each hold below shows up as a row, a card, or an inbox card.

How it behaves

The dependency one deserves its own line, because it is the likeliest reason a branch of yours is sitting finished but unlanded. The auto-lander will not land such a branch by itself — however green it is — until you tell it to: it holds a branch that changes outside packages — a package manifest's dependencies, a lockfile, the package-manager settings, or a patched or bundled package — a manifest's npm scripts, or code the auto-lander runs by itself — its gate-check scripts, the git merge helpers, or the file that tells git to use them. The first carries supply-chain and breakage risk; npm scripts are commands every developer runs; the last would run with nobody watching the next time anything lands. So all three ask, and the approval card says which the branch changes (since 2026-09-24 — before that, every one of these cards called itself a "dependency change", even for a branch that only touched the auto-lander's own scripts) and how many files moved; the files themselves are listed one per line in the card's details (since 2026-09-26 — before that the card's one-line headline named up to twenty file paths, long enough to push its Approve button off a phone screen). The details also list which packages the branch adds, removes or re-versions, one per line with the old and new version (sharp ^0.35.3 → ^0.35.4), marking new, removed, dev-tool and override entries — and they name any package.json that also changes something the list does not show (an install script, a build-script allowlist), so the list never passes for the whole change (since 2026-09-26). Versions that move only inside a lockfile are not itemized. A branch that only edits npm scripts is worded as exactly that, with no outside package added, removed or re-versioned (since 2026-09-25); if its install hooks or anything that installs packages moved too, the card still says outside packages. The card judges only what the branch itself changed since it started, so an edit master made to the same file in the meantime never mislabels the branch or holds it (since 2026-09-27). Every one of these notices now says when (since 2026-09-28). A note about a branch waiting on your sign-off carries the time its ready tag was set, so you can tell a note written before your decision from one written after it — before this, the two read identically, and a branch you had just approved still looked like it was waiting on you. It names the tag time rather than an "evaluated" time on purpose: a branch is re-checked on every pass, so the hold can be recomputed long after the tag, and calling that instant the evaluation would be its own wrong answer. A branch tagged before this existed simply shows no time, and nothing else about the wording changes. "Always allow" on these cards is permanent, and it is everywhere. Each of the three carries a caret whose other answer is to stop asking — drawn as Always allow — and for these kinds there is no narrower choice: one click turns "a dependency change waits for a person" into "every dependency change, on every branch, in every watched repository, lands from then on", for good, and it clears every waiting card of that kind at the same moment. Only your own click can write it, and Settings can revoke it. So if you want these branches to keep coming to you, decline the caret and answer the cards one by one. The card says nothing is lost, approving lands the branch within minutes, and leaving it parked is a valid answer: the branch and every commit on it stay exactly where they are, and it simply waits until you decide. A branch that genuinely can't be landed automatically is parked aside (recoverable) and shows here as Couldn't land, rather than nagging you to finish it by hand.

Your approval is never lost (2026-09-24). The approval card names up to 20 of the files the branch changes and counts the rest, so even a large change is one you can approve. If the app closes a card without your answer — it could not record it, or withdrew it — a fresh card comes back for the same branch; only your own approve or decline is final. And once you approve, the branch stops being listed as waiting on you straight away, even while the auto-lander is busy with other work, and lands on its next turn. The "blocked from landing" card points you to the approval card for these branches — a session cannot approve one of these changes for you.

A branch that would delete work that already landed is held (2026-09-23). Before anything lands, the auto-lander checks that the branch still carries every line the main branch picked up in the last week. A branch that would quietly remove some of it — usually an older copy of a file restored over newer work — waits with the reason it would remove work that landed on master in the last week. What happens next depends on what the repository can show about that file's copy, which the fix session reads first (npm run audit:dropped-work): it puts the lines back only when the copy is an old version master itself already replaced, or when the session finds a rebase or a replayed resolution lost them. If the drop looks intended it sets the branch aside for you or its author rather than reverting it. A check that cannot finish — a read that timed out on a very busy machine, say — holds the branch instead of passing it, and it is asked again on the next pass. That hold is the check's fail direction, and it is deliberate. The one thing it does not cover is a bug inside the check itself: that is caught, logged loudly, and the branch lands. Someone who removes that work on purpose records why in a commit (Dropped-work-approved: <why>), and the branch then lands normally. Before anyone signs off, the refusal shows the branch's whole change to each flagged file, not just the flagged lines, so a short code change sitting next to them is seen too.

Since 2026-10-07 that hold also survives main moving on without the branch. The check's answer is work the branch carries against work main carries, so main gaining commits can only make the refusal stricter — a file that was fine can become a drop, but a drop never clears on its own. The lander used to re-run the whole scan every time main advanced, which cost a scan and a few seconds of the lander's own limited budget per branch for no new answer. It now holds the branch on the branch's own tip, its ready tag and the repository it was asked about; a branch that is held and then re-tagged, re-committed or left alone while main advances quietly stops being retried until one of those actually changes. The one case left is a branch main has itself merged part of — the week-long window then slides, and the branch is scanned again, so the worst case is one extra scan behind a card you can already see, never a branch that lands without being checked.

The other one worth knowing is "a branch that changes a file git runs". Some branches change a file git itself executes the next time it runs — a git hook body, an executable .gitattributes rule, or one of the generated merge drivers. The auto-lander will not land those on its own, because the content would end up running as you in the folder it lands into. Until 2026-09-21 its only answer was "a person has to review this and land it by hand", which nobody ever did, so those branches simply sat — twelve of them had piled up. It now asks you on a card instead: approving one lands that branch within minutes, and nothing is lost either way. If you would rather not be asked again, the card's Always allow answer retires the whole class for good — and that grant is total: since 2026-09-21 there is no path carved out of it, so a branch that changes git's own guard on protected branches is covered by the same answer as any other. The only way to keep seeing those is to answer each card rather than grant the class.

The same file changed on both sides (2026-09-24). A branch whose merge touches a file that the main branch also changed cannot be checked automatically: git can show that both sides edited it, never that combining them kept both. So the auto-lander refuses to land it on its own and asks you on a card — the card lists the files at stake and, for each one, what it actually found: that both sides are still represented in the result, or that one side's work did not survive. Approving clears the check for that exact publication, including anything the card did not list, and the branch lands on the auto-lander's next pass. There is no Always allow on this one, on purpose: every one of these is a different question about different files, so a standing answer would not retire a class — it would switch the check off. Declining costs nothing and changes nothing: the branch stays where it is, and you are not asked about that same commit again.

For agents

Key files. The view is AutoLanderView.tsx in the Dev Pipeline panel; the queue read is the pure auto-lander-queue.ts behind the read-only AUTO_LANDER_QUEUE_GET IPC (handler); status + history reuse the existing AUTO_LANDER_STATUS_GET / AUTO_LANDER_EVENTS_GET. The daemon itself and its guarantees are in auto-lander-contract.md; the panel + this view's placement rule are in dev-pipeline-panel-contract.md.

The rejection list. Every standard the lander can refuse a branch for is a row of land-standards-catalog.ts; the mode resolver, the two routes, the landStandardModes setting and the build-failing guard that keeps every refusal in the catalogue are governed by auto-lander-land-standards-contract.md. The out-of-process land:catch-up mover — the same source-checkout-only developer tool named on the Auto-lander dashboard page — honours the environment switches only.

Related

This view belongs to the Dev Pipeline panel, whose other screens and their placement rules are covered in Dev Pipeline panel.

• Auto-lander dashboard — the view itself: live status, the queue and the land history.
• Auto-lander dashboard — part 2 — the catalogue of every reason the lander refuses a branch, and what happens after a land.