Engineering work happens in a temporary cloud sandbox, not on your machine. Uncommitted work does not survive.
This is the most consequential thing to understand before you ask Bright to touch code, and the easiest to learn the hard way.
Bright does not run on your machine
When an Engineer agent writes or fixes code, it works inside an ephemeral Linux sandbox in the cloud: a fresh, isolated clone of your repository created for that work. It is not your local checkout, and nothing in it touches your machine.
Nothing is durable until it is pushed
Changes made in the sandbox stay in the sandbox until the agent commits and pushes, or opens a branch or pull request. Until then, the work exists in one temporary place.
Uncommitted work is lost. The sandbox can be reset between sessions, when a session crashes or times out, or when another agent works in the same space. There is no recovery path for work that was never pushed.
Push at the end of every issue
Push after each issue rather than batching several together. Batching widens the window in which a reset destroys work, and it makes the loss harder to reconstruct.
- Clone the repository.
- Make the code changes for a single issue.
- Run the tests and verify the result.
- Commit and push before ending the session.
- Start the next issue from a clean base.
What this means for review
A session that reports code as finished has not necessarily preserved it. Treat a push, a branch, or an open pull request as the completion signal, not the agent’s summary. Verify at GitHub before closing the issue.