You are moving to a new machine in a few days, and a step-by-step rebuild guide was written for it today. Eleven of its questions cannot wait for the day itself, because each one either changes what the steps say, has to happen while the old machine is still whole, or gets set in the first ten minutes of the new one and is awkward to undo. The first question decides how much the other ten matter. Every one of them arrives with a recommendation, so this is you agreeing or disagreeing rather than deciding cold.
The new laptop can either be a copy of the old one or a rebuild of it, and that single choice turns roughly forty setup steps into either work or verification. The old machine has accumulated a specific kind of problem — settings typed into a box once, which now outrank the code and belong to no repository — and a faithful copy reproduces all of them silently, because a copy cannot tell configuration you meant from configuration that simply happened. Two facts sit underneath every question below and neither of them is a hypothetical.
No backup destination is configured, and no cloud folder holds a copy of the working area. Roughly eleven megabytes of it cannot be rebuilt from any repository: the record of what you have decided, the ledgers that hand out identifiers, and the program's own memory. If the drive failed this evening, all of it would be gone, and the first symptom would not be an error — it would be the machine coming up looking perfectly healthy and then asking you a question you already answered.
Agent writes to GitHub go out as the bot rather than as you, and what makes that possible is a signing key that exists in exactly one place: inside the old machine's system keychain. There is no exported copy, and GitHub will not show the original again. If the key does not travel, the new machine needs a fresh one and every repository holding a copy of the old one has to be updated — which briefly breaks automated builds if it happens in the wrong order.
There is a third thing worth stating because it is the reason one of the questions below has a deadline. The safeguard that keeps agent writes off your own name currently exists on this machine only, in a version that matches neither the shared repository nor the change that was supposed to introduce it. A rebuild that clones from the repository produces a machine without it.
Apple's migration tool copies a user account whole: the login credentials, the browser profile, the shell configuration, the tools installed under your account, and — the part that matters most here — the keychain. Take it and the GitHub login survives, the signing key survives, and three of the longest steps in the rebuild guide become things you confirm rather than things you do. It is also, by a wide margin, the fastest route.
What it cannot do is discriminate. The same pass that brings the key brings the permission list where most of the entries point at a project that has been dormant since May, the identity settings that make agent commits look like yours across thirteen checkouts, and the top-level instruction file that outranks everything else the agents read and lives in no repository at all. Those are the three problems the rebuild exists to fix. They are cheap to fix on an empty machine and expensive on a working one, because on a working one the fix has to be argued for against something that currently appears to function.
A fresh account on the new machine. Nothing comes across except the small local-only store, whatever documents you name explicitly, and repositories, which arrive by cloning. Every setting is chosen rather than inherited.
The migration tool, whole account. Fastest by hours; keeps the GitHub login, the signing key and the browser profile intact.
The migration tool, and then the three fixes applied by hand on the new machine, with the read-back checks at the end of the guide treated as the actual deliverable rather than an appendix.
Rebuild clean, which is what the guide recommends and what it is written for. The whole premise is that a faithful copy is the wrong outcome. If time forces the migration tool, take Option C rather than Option B, and treat the read-backs as the work rather than the paperwork — they are the only thing standing between a fast move and a machine that quietly still has all three problems.
The single strongest argument for copying the account is that the signing key survives. That advantage can be had under a clean rebuild too, and it costs nothing: generate the replacement key and update the repositories that hold it now, this week, while both machines are alive and healthy. Do it that way and the new machine never has a window where automated builds are broken, and the key stops being a reason to choose the faster route.
Each one names what is being decided and why it matters. Every recommendation below is the one the rebuild guide already makes, unless the box says otherwise — three of them are added or sharpened here, and those say so plainly.
The three options are above. This is the only question on the page whose answer changes what the other ten mean: under a clean rebuild they are choices, and under a copy most of them are already answered for you by whatever the old machine happens to hold.
The small local-only store has to reach the new machine somehow, and right now it exists on one drive with no copy anywhere. The realistic routes are an external disk, a proper backup destination you have been meaning to set up, or a direct machine-to-machine transfer with no intermediate copy at all. Only the first two leave you with anything if something goes wrong in the middle.
If one exists, the move is a restore and nothing breaks. If none exists — which is what the evidence says — then the new machine needs a fresh key, and every repository holding a copy of the old one has to be updated to match. Doing those two things in the wrong order breaks automated builds until both halves are done.
It has been open since Monday and it carries the safeguard that currently exists on the old machine only. Land it first and you are merging a two-day-old change under time pressure. Land it after and the new machine spends its first days with agent writes to GitHub attributable to you personally — and an edit cannot be re-attributed once it is made, so those days do not get cleaned up later.
Both are chosen while the machine is still setting itself up, and both are baked into more than the obvious places. The program's memory — the accumulated record of what has been decided and why — lives in a directory whose name is derived from the full location of the working folder. Change the account name or move the folder one level, and that store does not error. It becomes invisible: the machine comes up healthy, sessions start, and every question you have already answered gets asked again.
These two settings pull against each other for a machine that is supposed to work unattended. Encryption on means an unattended restart stops at an unlock screen and waits for you. Automatic login off means the scheduled background sweep — which needs a logged-in desktop session — stays dead after a reboot until someone physically logs in. Together they mean that any reboot silently stops the program.
Generating a new one lets you cut the old machine off cleanly the day you retire it. Copying the existing one makes the two machines permanently indistinguishable to GitHub, so retiring the old laptop becomes an act of faith rather than a revocation.
One wrinkle worth knowing before the day: a new key has to be authorised in a browser before your employer's repositories will clone, and that step announces itself by failing rather than by asking.
This file outranks every other instruction the agents read, has no repository, no history and no review path, and has already gone stale in two places that were then acted on. Two candidates: the harness repository, which holds the rules the file has to agree with, or the roadmap hub, which is where you go to read things. And a second half — install it as a link into the owning repository, so edits are live but a branch switch can swap the file out from under a running session, or install it as a copy that a script can check, which is how the existing hooks already work and which drifts until somebody re-runs the check.
It was built weeks ago, it is tracked, and it has never actually been installed. Rebuilding what the old machine had means leaving it off. Rebuilding what you meant to have means turning it on. A clean rebuild is exactly where that distinction quietly gets lost, because nothing on the new machine will remember that it was supposed to exist.
The old machine runs a version from April 2024. The automated builds run against the current release, which is now well ahead of it. Nothing anywhere pins a version, so "install the latest" produces a machine that runs fine and quietly does not reproduce this one — and "install the old one" produces a machine that reproduces this one and still does not match the builds. Those are two different targets and only one of them is checkable by a machine.
Nine hours of unattended work were lost to the lid closing, twice of those while plugged in. There is no setting for it on this generation of hardware. Either the lid stays open because you remember to leave it open, or you set up an external display, an external keyboard and mains power, which is the only combination in which the machine keeps running with the lid shut.
The rebuild guide ends with fourteen questions. Eleven are above. The other three are named here rather than dropped, because a list that silently omits things reads as complete.
| What it is | Where it went, and why |
|---|---|
| A block of settings describing a different, personal project, which has been judging this program's commands against the wrong trust boundary | Moved to the local configuration list. Stating the question in public would describe private family information; the decision itself is small and the recommendation is to move the block to where it belongs and where it is accurate. |
| How broad the new machine's GitHub permissions should be | Moved to the local configuration list. Describing what a live credential is currently allowed to do is not something to publish, and the recommendation — grant only what the program needs, and add anything else for the ten minutes you need it — does not require a page. |
| Whether the program's memory store should live in a private repository instead of being copied by hand | Deliberately deferred. The guide itself calls it the least urgent of the set and says it does not need resolving before the move. It is a real question and it should get its own page later, when the answer is not competing with a deadline. |
Two of those three now sit on the local configuration list, which is the same list the operations dashboard shows you, and each one carries the exact action and the exact check that says whether it is done. Neither is lost; both are simply somewhere a public page is not the right place to reach them.
The rebuild guide itself is a local document and stays local: it names where credentials live, and it is written so that it never names what they are. Nothing in it is reproduced on this page beyond what is needed to state each choice.
Sources. All eleven questions, and the recommendations attached to them, come from the new-laptop rebuild guide drafted on 2026-08-20 from an inventory taken on the machine itself rather than from memory. The absence of any backup destination and the absence of an exported copy of the signing key were both verified on the machine on the same day. Three recommendations are added or sharpened on this page and each is marked where it appears; every other recommendation is the guide's own, restated.
References. Requirement: obot.roadmap#279. The identity defect: obot.roadmap#260. The ownerless instruction file: obot.roadmap#261. The change carrying the attribution safeguard: obot.agent#198.
Drafted by 👯🤖 W0091 using Claude Opus 5. Not reviewed by @jwildfire.