Your cloud session's work comes home and lands itself

What it is

When a cloud session finishes with changes, its work comes back to this computer as an ordinary branch and is registered for landing. From that moment you should not have to think about it: the app tests that branch and lands it by itself (see which projects below), and the same machinery that lands every other finished branch takes it from there.

Before this, a returned branch sat and waited. It was registered and visible, but nothing tested it, so somebody had to notice it and run ready-to-merge by hand. That is the step this removes.

Where to find it

There is no screen to open: it works on its own whenever a cloud session brings work home. You follow it in that session's own transcript, and its one switch is in the Dev Pipeline panel.

What you will see

The cloud session's own transcript tells you: that the returned work is being tested, and then either that it is on its way or why it could not be. Nothing appears only in a log.

It also names, once, which project secret files that session received — or says plainly that none were sent. A session whose delivery was turned off or failed says so rather than staying quiet.

Turning it off

Dev Pipeline panel → Setup → Returned cloud work. Off, a returned branch is registered exactly as it always was and waits for you — nothing else changes.

The switch is on by default. It is inert unless you are using cloud sessions at all.

How it behaves

The app reviews the returned work too

When the work comes home, the app also runs the AI reviewers you configured in the Dev Pipeline panel against the returned branch — the same reviewers, and the same review, a session you run on this computer gives its own work before it finishes. It runs on its own, with nothing to ask you first.

This is the first moment a cloud session's work can be reviewed at all: a reviewer only runs on this computer, and the cloud machine's copy of your project does not come back until the session ends. So the review happens here, on the branch, the moment it arrives.

What you get: the reviewers' findings, filed against the cloud session whose work they read — so a finding about that session's branch shows up under that session, not under whatever happened to be watching. The branch keeps them.

What it does not yet do: stop the branch landing. A serious finding is delivered to you and recorded; it does not currently hold the branch back. The hold is the next piece of work in this area, and it is written down as owed rather than implied. Until then, treat a returned branch as reviewed but not necessarily approved.

A review that could not run — no reviewer configured, or one that cannot start — is recorded and says so. A branch is never quietly marked as reviewed when it was not.

To turn it off: Dev Pipeline panel → Setup (the review switch), which sits beside the returned-work switch described below.

Which projects it runs for

Every project, by one of two roads. A checkout of this app is tested with the app's own checks and marked ready to merge, and the usual landing takes it from there.

Any other project is judged by the only test it ships for itself: its own test command, run on the cloud machine against the very files coming home. When those tests pass, the branch is merged onto that project's own main branch here on this computer. Nothing is merged when the project has no real test command, when its tests fail, when the run hits its time limit, or when the branch changes its own test setup (the project's package file, a lockfile, or the test runner's configuration). The branch is then registered exactly as it always was, and the session tells you in one line why it was left for you to review and land yourself. You will not be asked about it again.

What it will not do on its own

Six things stay in your hands, on purpose:

• A branch that changes a dependency or a lockfile is never landed automatically. It is held and you are asked, the same as any other branch that moves a dependency.
• A branch that genuinely conflicts with what it is merging into is reported as a conflict, and left alone. The files that clash are named for you and the app does not resolve them on your behalf — that call is yours. It is reported as exactly this, and never as a check that could not run, because the two ask different things of you.
• A branch whose files could not be checked for secrets is refused, not landed. If the check cannot be completed — a file that will not open, rules that will not load — the answer is no rather than a guess in your favour. The check uses the app's own rules, so it works the same way for every project; and when it refuses, it names the files, never the value it found.
• A branch is only ever marked ready off a check that covered that branch's own files. A passing check from somewhere else is not evidence about your work.
• A finished answer is not re-asked. A red check, a branch that will not merge, a claim it does not carry — each of those stops the automatic step and tells you why. Only a check that never finished is tried again, and only a bounded number of times.
• A branch that stops is never silent. Its own session has usually ended by the time its outcome is known — a capture runs when a session ends — so the outcome is reported to the session that launched it, or raises one notice naming the branch. A stopped branch waiting for something only you can do always says so.

How project secret files are handled

A cloud session starts on a copy of your project, and a copy taken by git leaves behind exactly the files a .gitignore names — which is the point of a .gitignore, and also why a cloud session used to be unable to run any test that needs a key. So your project's own ignored .env family (.env, .env.local, .env.production and the like) can be sent when secret delivery is enabled, at the same relative paths it has here.

What that means in practice:

• Only the .env family travels. Not .npmrc, .netrc, .envrc, .pgpass, .git-credentials, .htpasswd or .pypirc — those are logins to other services, not this project's own settings — and not a committed template like .env.example, which already ships with the project.
• A folder your project has declared off-limits for the cloud stays off-limits, even if it holds a .env.
• The app attempts to delete them before stop and before capture. A failed cleanup is reported, but preserving work and stopping billing take precedence. A stopped disk or whole-tree capture archive can therefore retain secret files.
• Delivered ignored files are kept out of returned commits. A clean branch is not proof that its transfer archive contains no secrets.
• The session is told which ones it got, by name, in its own transcript — so an agent never has to guess whether a key it needs is there.
• Secret values are not printed in messages. Not in a log, not in the transcript, not in the session's notice — names only.

The one honest caveat: a cloud session approves its own actions and has open internet, so an agent running there can read these files, exactly as an agent on your own computer can. Your decision to send them is what this feature is; what bounds them is the list above.

Related

How a cloud session starts in the first place — and how later sessions start from a saved copy of your project instead of a full upload — is on Starting a cloud session from a saved copy. A returned branch that is marked ready lands through the same auto-lander as every other finished branch: the Auto-lander dashboard shows it waiting, landing or being handed back, and the panel's Setup tab, where this feature's switch lives, is described on Dev Pipeline panel (part 2). The same idea on your own computer — a session working in its own copy of your project and bringing the work back when it ends — is Session isolation.