Work handed to a cloud session comes back, or says why not

Typed links: builds_on itd-2609091034175565 (reservations on the shared remote, being built now: a cloud session reserves the item it takes, which is how every other session, local or cloud, sees that it is held; this record adds nothing to the reservation itself); related_issues, the six findings of 2026-10-12 this record answers, each listed under Why This Matters. related_intents, prose relations no typed field carries: itd-2609150819440345 (the wider register of running sessions, kept for later; this record's list covers only the cloud sessions abcd briefed, read from the remote), itd-152 (shipped: tool footers and session links leaking from cloud runs into public text; a report this record posts publicly is held to that same outbound check, nothing more), itd-107 (routine prompts assembled from one versioned template; the cloud brief here is a one-off brief for one item, and may later become one of that template's archetypes) and itd-22 (the host-profile seam: the host connector this record's first rung writes for one host, decision 1, is a piece of that seam, not a second one). related_adrs: adr-2610120937435856 (the trust rule this record's work-in-progress branches need, decision 3; brief invariant 23).

Press Release

A person hands any item that is ready to build, from a small fix to a planned feature, to a cloud agent session as easily as to a session on their own computer: abcd starts the session itself, and the work comes back, or the session says why it could not. The cloud session runs with the same abcd tools the person has, on a machine abcd prepares with the same checks, run as an ordinary user rather than as the machine's all-powerful one, and checked before any work starts, so a session never finds out halfway through that it cannot pass the project's checks. It gives the session a brief that says what to work on, whose name the work goes out under, and how to stop and report. Every session, finished or stopped, pushes its work and its report to a work-in-progress branch, even when the cloud machine could not pass the checks, so nothing is left behind in the cloud, and one list shows each cloud session's item, branch and report, so nobody copies a report out of a transcript by hand. A work-in-progress branch never reaches the main branch on its own: nothing from the cloud lands until it has passed the checks again on the person's own computer. Because pushed work is public, abcd never hands a cloud session an item that is not public yet, such as a private security report. When the cloud cannot be reached, or the login abcd starts sessions with has run out, abcd says so before anything starts, instead of quietly running the work on the person's own computer. It starts with one host's cloud sessions; other agent hosts plug into the same place later.

"On the day I moved three fixes to the cloud, two things went wrong at once," said Maya, an autonomous-development practitioner. "The sessions I meant for the cloud started on my laptop without telling me, and the ones that did reach the cloud finished their work, failed checks their machine could not pass, and kept everything to themselves. I copied one report out of a transcript by hand and redid its fix locally. Now I tell abcd which item to send, the session checks its own machine first, its work and its report come back on a branch even when its checks failed, I read every session's report from one list, and what comes back passes my own checks before it lands."

Written by an agent from the six findings of 2026-10-12. The product thinker answered Q1, Q2 and Q5 to Q11 on 2026-10-12; the technical facilitator decided Q3, Q3b and Q4 the same day on the product thinker's delegation, and planned the record (see Decisions). The press release, the criteria, the scope conditions and the Mechanism were revised to match and stand as the plan the build follows; the product thinker reviews them on return, and a change then is made through the record, not around it.

Why This Matters

On 2026-10-12 three issues that needed no decision were moved to cloud agent sessions, and every step of it was done by hand or went wrong quietly:

• The work started in the wrong place, silently. The requesting session's sub-agents could not reach the cloud and started on the person's own computer instead, in worktrees under the checkout (.claude/worktrees/), and other sessions learned of it only when the requesting session corrected its own announcement (iss-2610120729076366).
• The real cloud sessions were started by hand. The person launched them in the browser with briefs a local session wrote; nothing in abcd composes such a brief, lists the running sessions or collects their results (iss-2610120729071657).
• The cloud machine could not pass the project's checks. The container ran everything as root and had no gitleaks, so tests that prove abcd refuses a path other accounts can write, and gitleaks-backed checks, failed on work that did not touch them; one failure reproduced on an unchanged copy of the default branch there (iss-2610120724251698). Nothing prepares or checks a cloud machine the way the person's own computer is prepared (iss-2610120729094755).
• Finished work was trapped. Without a passing preflight there is no receipt, the push hook refuses the push, and skipping the hook is forbidden, so a finished fix (two commits and a resolved record) stayed in the container and was redone locally (iss-2610120729087253).
• The reports stayed in transcripts. The person copied one session's stop report into a local session by hand; the other two were still unread when the findings were filed (iss-2610120729083126).

A second person now works on the project from another computer, and a cloud session has no machine-local state in common with either of them: it shares only the remote. Whatever lets the person send work out and get it back has to live where the cloud session can reach it, which is the same ground the reservation record (itd-2609091034175565) stands on.

What the host offers today (evidence, 2026-10-12)

Read from the host's documentation on 2026-10-12 (code.claude.com: claude-code-on-the-web, cloud-environments, routines, self-hosted-environments, settings-reference) and GitHub's rulesets documentation; a coordinator's research, not yet re-verified in a live session:

• Launch. A cloud session can be started from a terminal with claude -p "<prompt>" --environment <env-id> --ref <branch> --output-format json, which returns the session's id and link; a follow-up is sent with --cloud <id>. Re-read on 2026-10-22 (iss-2610222040438242): --environment takes only a self-hosted environment's ccpool_ id and rejects an Anthropic-hosted env_ id, --ref applies only with it, and an Anthropic-hosted session is started with claude --cloud "<task>", whose output on creation is not documented (iss-2610222106115276). It needs a claude.ai login whose refresh lasts at most 30 days. Routines have a REST fire endpoint, in beta.
• No way to list or read sessions. There is no documented interface to list cloud sessions or read their results: what a session produces comes back only through what it pushes. A local sub-agent cannot run in the cloud; it runs where its session runs, which is how the 2026-10-12 lanes ended up on the person's computer.
• The machine. Hosted sessions run as root on Ubuntu, and the base image cannot be replaced. A setup script stored with the claude.ai environment (not in the repository, cached for about five minutes), or a repository session-start hook gated on CLAUDE_CODE_REMOTE=true, can install a pinned gitleaks and the toolchain. Creating a non-root user and running preflight as that user is untested. Self-hosted environments (Team and Enterprise plans, beta) allow a non-root image. A shell command times out after two minutes by default and ten at most (longer in the background, adjustable by environment variables); the machine has about 4 CPUs and 16 GB.
• Branches. Sessions push to claude/-prefixed branches. The forge proxy refuses any ref that is not a branch, so a custom namespace such as refs/abcd/wip/* cannot work; it refuses deletions; and it blocks the forge's GraphQL interface, so gh pr and gh issue fail while gh api over REST works. Keeping such branches off the default branch takes a ruleset plus a CI check that fails on a source branch matching claude/**.
• Attribution. The host adds an AI co-author trailer and a session link to commits by default; the repository's .claude/settings.json (attribution.commit, attribution.sessionUrl) switches them off, though one report says the link can survive, so abcd's attribution gate stays the check. The git author inside the machine is not documented and has to be set explicitly.

Decomposition (revised to the answers of 2026-10-12; routing adopted by the technical facilitator on delegation)

Run by hand under decompose-before-filing; not yet graded into the calibration note, which waits for the product thinker's review of the routing on return.

Overall verdict: SPLIT. This record files the four capability parts and the embargo refusal, with the host connector as a design constraint across them; the trust rule is adr-2610120937435856 and invariant 23; two halves of the findings stay on their own issues.

Mechanism

The technical facilitator's proposal of 2026-10-12, written on delegation because the draft left it open; for the product thinker's review on return.

We expect work handed to a cloud session to come back, or say why not, without any step done by hand, because the only thing a cloud session and the person's computer share is the remote, and this design puts every piece of hand-back on it: who holds the item (the reservation), the work itself, checked or not (the work-in-progress branch), and what happened (the report file committed on that branch). Every failure of 2026-10-12 was a step that depended on something not on the remote: a transcript, a receipt the cloud could not mint, a sub-agent that ran locally instead. Trust does not move to the cloud, because the person's own collect re-runs the checks (decision 9), so admitting unchecked work to the remote widens nothing that lands.

This would be shown wrong if, on the proof rung or on the first three items handed off after it, a result still has to be copied out of a transcript or redone on the person's computer for any reason other than a check that genuinely fails: for example, the hosted proxy refusing the work-in-progress name, the non-root user unable to run preflight there, or a report that reaches neither the branch nor the tracking issue.

Scope Conditions

• Holds for the hosted cloud sessions of claude.ai, started through abcd's plugin for that host (decision 1). Another host (opencode, for example) is out of scope until a connector for it is written; nothing outside the connector may assume the first host.
• Holds on abcd's own repository first. A managed repository is a later rung, and its version must leave that repository's own git settings, hooks and tools as they are.
• Hypothesis until the first rung proves it: the hosted machine lets the setup step create a normal (non-root) user and run every check as that user (decision 8). Untested on 2026-10-12; if it cannot be done, C1 fails and the runner is re-decided.
• Holds while the person renews the host login by hand at most every 30 days (decision 11). A run that meets an expired login stops and says so; it never keeps going on a stored credential.
• Holds while the plan's own limits are the only cap on concurrent cloud sessions the person wants (decision 6); abcd counts sessions and refuses none for their number.
• Hypothesis until the first rung proves it: the hosted machine's forge proxy accepts a push to the connector's work-in-progress name, claude/abcd-wip/<item-id> (decision 3). If it refuses, the session's work cannot leave the cloud under invariant 23, and the prefix is put back to the person (decision 3).
• Holds while the forge's REST interface is reachable from inside the session, which the fallback report comment (decision 4) needs when the push itself fails; the GraphQL route is blocked there.
• Holds while unfinished work on a public repository may be public: a work-in-progress branch is readable by anyone who can read the repository, which the facilitator accepted (decision 3) and C13 bounds by never handing out an item that is not public yet.
• Holds while the person's own computer can run the full preflight: every cloud result is re-checked there before it lands (decision 9), so a cloud session never lands work on its own.

Acceptance Criteria

Agent-seeded, revised on 2026-10-12 to the product thinker's answers and the facilitator's delegated decisions (Decisions). They cover the first rung only: built first as scripts under script-first-mvp, on abcd's own repository, the smallest version that removes the hand work of 2026-10-12. Hosted sessions push to claude/* branches by default, and the forge proxy accepts only branches; the first host's connector declares the work-in-progress prefix claude/abcd-wip/ (decision 3). Planned by the technical facilitator on delegation on 2026-10-12; the product thinker reviews them on return.

• C1, the machine is prepared, and nothing runs as root. Given a fresh hosted cloud container for this repository, running as root with no gitleaks, when the session starts and the repository's cloud-only setup step (C11) runs before anything else, then a normal (non-root) user exists and owns the checkout, gitleaks, the toolchain go.mod declares, the committed git hooks and the person's author identity (taken from the environment's forge token, decision 18) are in place for that user, and make preflight on an unchanged copy of the default branch, run as that user so that no command time limit cuts it short, either passes and mints a receipt or fails only on the gates the check (C2) named in advance; no check of this criterion or of C2 runs as root, and the whole is proved once in a real cloud session, because running as a non-root user there is untested (decision 8).
• C2, the machine is checked before work, and stops only for what the final checks need. Given a container in which one prerequisite is missing (gitleaks, for example), when the session runs the environment check, then the check names each missing prerequisite, the setup step that supplies it and the final checks that need it, and changes no file in the checkout; if any of preflight's gates needs the missing tool, the session stops before any work and reports why (C6), and otherwise it warns and carries on. Which tool each gate needs is read from one list abcd keeps beside the gates (decision 5).
• C3, a brief started in the wrong place stops. Given a brief written for a cloud session, when it is started on the person's own computer instead (for the first host, CLAUDE_CODE_REMOTE unset, a test the host connector owns), then its first step reports that it is not running in the environment the brief was written for, and the session starts no work.
• C4, one brief per item. Given an item that is ready to build, either an open ledger item or a planned intent whose readiness gate passes (decision 7), when abcd composes the cloud brief for it, then abcd produces one brief naming the item, the rule that every commit is authored under the identity the setup took from the forge token (decision 18), the setup and check step to run first, the rule that no hook is skipped, the branch the work goes to (the host connector's work-in-progress prefix followed by the item id, claude/abcd-wip/<item-id> for the first host), where the report goes (a report file on that branch, and the tracking issue only when the push fails, C6), and the brief carries no session link, no path on the person's computer and no secret.
• C5, no quiet fallback, and an expired login stops the run. Given a request to send an item to a cloud session, when the cloud cannot be reached (no login, an expired login, an unknown environment, a launch the host refuses), then the person is told the cloud cannot be reached and why, and nothing is started on their own computer in its place: no local session, sub-agent or worktree; an unattended run that meets an expired login stops there and says that the person must renew the login by hand (decision 11).
• C6, every session reports, on its branch. Given a cloud session that ends, having handed back its work or having stopped because a check failed, when it stops, then it commits its report (what it did, what failed, what it needs from the person, and which channel it used) as .abcd/work/cloud-reports/<item-id>.md in a final commit of its own on its work-in-progress branch and pushes it with the work; only when that push fails does it post the same report, saying the push failed and why, as a comment on the project's one tracking issue for cloud sessions through the forge's REST interface, before it exits; and either form passes abcd's outbound check, carrying no session link and no tool footer (decision 4).
• C7, finished work is not trapped, and never reaches the default branch on its own. Given a cloud session whose commits cannot earn a preflight receipt there, when it pushes them to <wip-prefix><item-id>, then the push hook admits that push without a receipt as one entry of its declared list of receipt-less prefixes, with the prefix read from the host connector's declaration and the entry ruled by adr-2610120937435856; it refuses without a receipt every other branch, including any other branch in the host's own namespace, a work-in-progress branch whose name is not the prefix followed by one valid record id, and one whose pushed commits fail the attribution gate; it refuses a declaration whose prefix does not end in the segment abcd-wip/ or holds more than one segment before it; and a pull request or merge-queue entry into the default branch from a source branch holding the segment abcd-wip, or whose diff adds a file under .abcd/work/cloud-reports/, fails a required check the default branch's ruleset names (decision 3, invariant 23).
• C8, one list of cloud sessions. Given three cloud sessions abcd started, one that handed back its work, one that stopped with a report and one still working, when the person asks abcd for the list of cloud sessions, then it shows each one's item, branch, state and report, read from the shared remote alone (the work-in-progress branches, the report file on each and the reservations), plus the tracking issue's comments for a session whose push failed (there is no interface to list cloud sessions), with the session still working shown from its live reservation, and no transcript is opened.
• C9, handed-back work lands through the person's own checks. Given a branch a cloud session pushed, when the person collects it, then abcd runs preflight on a copy of it on the person's computer and, only if it passes, offers it for landing as a branch whose commits name the person as author, carry an Assisted-by: trailer and no AI co-author trailer or session link, with the receipt minted locally and the report's own commit left out of it; a failing copy is reported with its failures and nothing is pushed; and no receipt minted in the cloud is trusted in place of this check, even one that passed there (decision 9).
• C10, abcd starts the session. Given an item that is ready to build and a valid host login, when the person asks abcd to send the item to a cloud session, then abcd starts one cloud session through the host connector with that item's brief (C4) and reports the session's id and link to the person, who takes no step in the host's own interface; a start the host refuses is C5's case (decision 2).
• C11, the cloud session runs the full abcd toolchain. Given a fresh hosted cloud session for this repository, when it starts, then the repository's committed Claude settings file has enabled the abcd plugin from this repository's own marketplace, switched off the host's AI co-author line and session link, and run the setup step (C1) because CLAUDE_CODE_REMOTE is set; the same file on the person's own computer runs no setup step; and a commit the session makes carries neither the co-author trailer nor the session link, with abcd's attribution gate still the check (decision 10).
• C12, everything host-specific sits behind the host connector. Given the first rung's scripts, brief template and the files they add, when everything outside the host connector is searched for the first host's markers (its name, its command-line tool, CLAUDE_CODE_REMOTE, its environment ids, its work-in-progress prefix claude/abcd-wip/), then none is found, the push hook and the required check match only the connector's declaration and the host-agnostic segment abcd-wip; the host's own files that it reads at fixed paths (its settings file) belong to the connector though they sit where the host reads them; and a test proves the search, so a second host is added by writing a connector and changing nothing outside it (decision 1).
• C13, nothing private goes to the cloud. Given an item that is not public yet (its record is absent from the remote's default branch: a draft never pushed, a record only on a local branch, or a private record in the embargo store) or one the embargo store on this machine holds, when the person asks abcd to send it to a cloud session, then abcd refuses before composing a brief or starting anything, names which of the two reasons applies, and starts nothing on the person's computer in its place; when an embargo store exists on the machine, the composed brief for a public item is passed through abcd embargo check first, and a store that exists while that check cannot run is a refusal, never a pass; and a test proves each refusal (decision 14, from the security rule).

Left out of the first rung

• The Go verbs. The first rung is scripts and a brief template; the core absorbs the contract they prove, as script-first-mvp requires, in a later rung. A coordinator's sketch of that later shape is a dispatch verb (launch, keep the session id with the record) and a collect verb (C9).
• Repositories abcd manages other than its own. The setup and check are proved on abcd's own repository first; a managed repository's version must leave that repository's own git settings, hooks and tools as they are (principle abcd-fixes-what-it-adds, adopted on the default branch on 2026-10-11).
• Hosts other than claude.ai's hosted cloud sessions (opencode, for example), and the other runners Q1 weighed (a self-hosted environment, a machine the person runs, GitHub Actions). Other hosts follow later through their own connector (decision 1).
• A cap on concurrent cloud sessions enforced by abcd. There is none beyond the plan's own (decision 6); the first rung counts at most.
• A login kept for abcd in a credential store. The person renews the host login by hand (decision 11).
• Merging handed-back work automatically. C9 offers a passing copy for landing; the person, or a local session under the usual rules, opens and merges it.
• Messages between cloud and local sessions while they run; reports are read after the fact. The session mailbox is itd-2609151838312703's, and it never leaves the local network.
• The wider register of running sessions (itd-2609150819440345).
• Recurring cloud routines and their template (itd-107).
• Deleting spent work-in-progress branches. The proxy refuses deletions; a sweep from an ordinary machine is the reservation record's tidy-up route (itd-118).
• The two issue-local halves: the worktree guidance (iss-2610120729076366) and the tests that should name their prerequisites (iss-2610120724251698), routed above.

Decisions

Ruled by the product thinker on 2026-10-12, answering the draft's open questions (numbered by the question each answers):

1. Q1, the runner: "Anthropic's hosted cloud sessions first, through the Claude plugin." With it, a constraint: other hosts (opencode, for example) follow later, so the runner sits behind a host connector, and nothing outside that connector names one host. Reason: it is what was used on 2026-10-12 and can be started from a terminal, and the connector keeps abcd's core host-agnostic (adr-39, itd-22). Criteria C10 to C12.
2. Q2, who starts the session: abcd starts it. Settled without a question by the product thinker's own statement, "I'd like abcd local to orchestrate this in future", which leaves one defensible answer. Criterion C10.
3. Q3 and Q3b, work-in-progress branches and their prefix: yes, and the connector owns the prefix. Decided on 2026-10-12 by the technical facilitator on the product thinker's explicit delegation that day: "decide the deferred item so that you can plan the intent. I want it ready to be build in a few days (while I'm away)". A cloud session that cannot pass the checks still pushes its work to a work-in-progress branch, so nothing is trapped; the push hook admits such a branch without a preflight receipt as one entry of its declared list of receipt-less prefixes (the list the reservation build introduces), and a ruleset plus a required check that fails on a work-in-progress source branch keep it from ever reaching the default branch. Reason: decision 9 already re-checks every cloud result on the person's computer, so the receipt was never what made cloud work trusted; the risk the receipt guarded, unchecked work landing, is held by the ruleset, the required check and the local collect. Cost accepted: on a public repository unfinished work is public. Q3b: the host connector owns the prefix and the host-agnostic core never names it; for Anthropic's hosted sessions it is claude/abcd-wip/<item-id>, inside the host's own branch namespace in case its proxy admits only that, and narrow enough that a person's own hand-pushed claude/ branches still need a receipt. That the proxy accepts a push to that name is a scope condition the first rung proves. The facilitator's fallback, if the proxy refuses the name, was the session's assigned branch with the report saying so; at planning that was found to need the hook to admit a branch outside the declared prefix, which invariant 23 forbids, so a refusal at the proof rung puts the prefix back to the person, and a refusal during a later run sends the report through the tracking-issue fallback (decision 4) naming the refusal. Ruled by adr-2610120937435856 and brief invariant 23. Criterion C7.
4. Q4, where reports go: a report file committed on the work-in-progress branch, with a comment on the one tracking issue as the fallback. Decided by the technical facilitator on the same delegation, revisiting the provisional answer as it said it would once Q3 was answered. The report file travels with the work, and abcd's list and collect read it back reliably without forge access; the comment on the tracking issue, through the forge's REST interface, is used only when the push itself fails, which keeps the product thinker's provisional reason (it is the only channel that works when nothing can be pushed). Criteria C6 and C8.
5. Q5, a missing tool: "Stop only for what the final checks need, warn for the rest." abcd keeps the list of which tool each final check needs. Reason: a session stops only where its hand-back would fail; the accepted cost is a list that can go stale. Criterion C2.
6. Q6, concurrency: "No limit beyond the plan's own." Reason: nothing to build or keep; the accepted cost is that a burst of sessions can spend limits the person's own sessions also need.
7. Q7, which items: "Any item ready to build, planned intents included." Reason: more work can leave the person's computer; the accepted cost is that a longer run is likelier to stop on a question, which only its report carries back. Criterion C4.
8. Q8, root: no; "the setup creates a normal (non-root) user on the hosted machine and every check runs as it." Reason: the cloud runs the same gates as the person's computer, including the tests that prove abcd refuses a path other accounts can write; it is untested, so the first rung proves it. Criterion C1.
9. Q9, trust: "Every cloud result is re-checked on the person's computer." No receipt minted in the cloud is trusted. Reason: every commit that lands has passed the gates on a computer the person controls; the accepted cost is that every cloud result waits for a local collect. Criterion C9.
10. Q10, the host's files: "Cloud sessions use the full abcd toolchain." The project keeps a Claude settings file that enables the abcd plugin from this repository's own marketplace, switches off the host's co-author line and session link, and runs the setup step on cloud start only (gated on CLAUDE_CODE_REMOTE); other hosts get their equivalent through the same connector. Reason: the setup is versioned and reviewed with the code and attribution is off before the first commit, and the file belongs to the host connector (decision 1), so the host is named in one place. Criterion C11. Agent note for the planning interview: the marketplace serves abcd's last published release, so in a cloud session on this repository abcd's verbs still run as go run ./cmd/abcd, as AGENTS.md requires of any source checkout.
11. Q11, the login: "The person renews the claude.ai login by hand, at most monthly." Reason: nothing new is stored; an unattended run that meets an expired login stops and says so. Criterion C5.

Decided without a question, each the one defensible answer on the record (moved here from the open questions' preamble):

1. The work goes out under the person's own author identity, set explicitly in the brief, because every commit names a human author and an AI co-author trailer is never used (AGENTS.md, attribution).
2. A cloud session hands work back only as a branch, because the forge proxy accepts nothing else.

Decided by the technical facilitator on 2026-10-12, on the delegation quoted under decision 3:

1. An item under a security embargo, or any record not yet public, is never handed to a cloud session, because pushed work is public; the refusal names the reason. From the security rule (abcd adds no vulnerability). Criterion C13.
2. The open note on decision 10 is resolved by the design, not by a new rule. .claude-plugin/marketplace.json serves abcd's last published release, so in a cloud session on abcd's own repository the plugin the settings file enables supplies the hooks and the command pages, while every abcd verb runs as go run ./cmd/abcd from the checkout, as AGENTS.md already requires of any source checkout; the setup step installs the toolchain go.mod declares so that go run works, and the brief and the setup tell an abcd source checkout to use go run. A managed repository, a later rung, uses the released binary.
3. Planning acts. The Mechanism is the facilitator's proposal, marked for the product thinker's review; the grounds are recorded as pursued; the impact is additive (a new capability; nothing existing changes for a person who does not use it).

Ruled by the product thinker on 2026-10-15, after a probe in a real hosted session found the clone's git identity set to the host vendor's default while the forge credited the push to the person's own account through the environment's token (captured as iss-2610152046379890):

1. No manual step sets the author identity. When git's identity in a session is a vendor's rather than a person's, abcd works out the person's identity itself from the forge token the environment already holds, instead of refusing and naming a setting for the person to change. The lookup is one primitive, shared with session announcements and reservations (spc-2610150728396006's holder), never a second copy. This narrows decision 12: the work still goes out under the person's own identity, but a cloud session takes it from the token, so the brief no longer carries an author read from the person's computer.
2. The vendor identity is shown nowhere. At session start in a cloud container, the setup sets the clone's local git identity from the token, the forge login as the name and the no-reply address built from that login and the account's numeric id as the email, before any commit, so every commit the session makes is authored as the person. If the lookup fails, the setup sets nothing and says so once, without repeating the vendor identity in any commit, ref, trailer or output, and the session's first step stops before any work, since no commit could be authored as the person. Criteria C1 and C4.

Left for the product thinker's review on return, because the planning was done on delegation without them: the Mechanism claim, the grounds, the confirmation of the scope conditions and the walk of every criterion. A change they make then is made in this record and its spec before the step it touches is built.

SOTA

Surveyed on 2026-10-23; sources, evidence tiers and the local fit risks are in the autonomous-loops SOTA note. The host's surface was read on 2026-10-12 and re-read on 2026-10-22; this pass checks the hand-back contract against comparable hosted agents and against what the host added since.

• The first host's cloud surface today. claude --cloud "<task>" clones the remote at the current branch ("push first if you have local commits"); claude -p "<message>" --cloud <session-id> queues a follow-up and returns {ok, session_id, url} as JSON; --teleport <session-id> pulls the session and its pushed branch into a terminal; there is still no scriptable or machine-readable listing of cloud sessions (--teleport with no id opens an interactive picker, and /tasks lists background sessions in a session); an expired environment restores the conversation but not background work; and per-account "projects" now coordinate parallel cloud threads, in public beta on individual plans only (Claude Code docs).
• The host's own hand-back is a report to a vendor-held conversation. A thread "reports back to the conversation when it finishes", works on its own branch and opens a pull request when the work calls for one; when threads stall, the advice is to ask each what it assumed, could not reach and waits on, and to "fix the gap once" (Claude Code projects docs).
• Comparable agents hand back a branch and a log, under a hard cap. A second vendor's coding agent works in an ephemeral environment, on one branch and one pull request per task, leaves session logs, and stops at a 59-minute cap that "cannot be extended or bypassed" (GitHub docs). A third vendor's CLI can "list recent cloud chats and check their status" (Codex cloud docs), a scriptable listing the first host lacks.
• Branch protection governs pushes as the connected access, so a rule that access can bypass does not block a run (Claude Code scheduled tasks docs); the proxy's branches-only rule is in the 2026-10-03 note.

Path 2, the planned contract confirmed (work-in-progress branch, report file on it, tracking-issue comment only when the push fails, list and collect reading the remote alone), with one addition the comparable systems argue for: a hard cap and an expiring environment mean work exists only once pushed, so the brief directs a push of the work-in-progress branch after every commit and a report written early as "started" and overwritten at the end, so a session cut off mid-task still leaves a branch and a partial report. The host connector remains the seam: a host that offers a listing may enrich the list, and the remote-only read stays the floor. No Go dependency. The independent fit-challenge is still owed before the build, and the questions below are kept for it.

Questions this pass raised for the fit-challenge before the build. They are kept here, not under Open Questions, so they do not hold a build the record already rules ready:

• Whether C4's brief directs the session to push its work-in-progress branch after every commit and to write the report file early as "started", overwriting it at the end, so that a session cut off by a time cap or an expired environment still leaves a branch and a partial report; C6 and C7 today speak only of the end.

Open Questions

None. Q3, Q3b and Q4 were decided on 2026-10-12 by the technical facilitator on the product thinker's delegation (decisions 3 and 4); every other question was answered by the product thinker the same day.

Audit Notes

Empty. Populated by intent-auditor when intent moves to shipped/.

Grounds

• pursued: (technical facilitator, on the product thinker's delegation of 2026-10-12, for review on return) we expect that putting the hold, the work checked or not, and the report of every cloud session on the shared remote ends the hand work of 2026-10-12, because every failure that day depended on something that was not on the remote; it is wrong if, after the proof rung, any of the first three items handed to the cloud still needs its report copied out of a transcript or its fix redone locally for a reason other than a check that genuinely fails.