Remote access is most useful when it preserves the work already happening on your computer. You should be able to leave the desk, open the paired experience from a browser or phone and continue against the same desktop project rather than starting a second cloud task.
Upfyn treats the desktop as the engine and the remote surface as a relay client. That choice preserves task context, local tools and Git state because there is only one execution environment to continue.
What the browser is
The browser at app.upfyn.com is a way to reach a signed-in, paired desktop. It can show the conversation and expose the remote controls supported by that connection. It is not an independent hosted machine with its own copy of the project.
This means remote access does not require a separate upload workflow. The files remain where they were, and actions still run under the desktop’s mode and permissions.
It also means the desktop must be running and connected. If the machine is asleep, powered off or remote access is disabled, the browser cannot continue local execution. The product should report that state plainly.
Why Git-state continuity matters
For development work, the state of a task is more than its messages. It includes the current branch, uncommitted changes, generated files, running services and terminal history. Moving the task into a fresh cloud checkout would lose or duplicate parts of that state.
A relay avoids that split. When you return remotely, Developer still sees the project on the desktop. The same caution applies: inspect the current Git state before making changes, preserve unrelated edits and do not treat remote control as permission to reset or overwrite work.
The useful handoff is therefore between screens, not between execution engines.
Pairing should be deliberate
Remote access is off by default. The user enables it, signs in and pairs a device to the account. Pairing should make the target desktop recognizable so a person does not accidentally connect to an old or similarly named machine.
The account dashboard should list signed-in devices and sessions across the website and product surfaces. A user can review and revoke them. Revocation is a security action, not a preference: a revoked session should stop being accepted by the gateway and desktop access path.
Use a clear device name and remove sessions you no longer recognize. Shared browsers should not remain paired after the work is complete.
Relay security and local authority are different layers
The relay protects the path between the remote client and desktop. The desktop still decides what the assistant may do once a request arrives. A secure connection does not convert a read permission into write permission or bypass a confirmation.
Analyst keeps its output boundary during a remote session. Developer retains its project and tool policy. Browser automation, connector writes and computer actions continue to use their existing approvals.
This layered model is important because account access and task authority solve different problems. Authentication answers who is connecting. Permissions answer what that session may do.
Remote access and Operator are not the same
Remote access lets you reach your own paired desktop through your account. Operator creates a one-time remote-assistance session between a host and a helper. The host approves the person, the client confirms and input control is granted explicitly for that session.
Operator can share the screen and optionally grant mouse, keyboard, text or clipboard control. Its optional AI operator is off until enabled, and AI-authored actions require consent on the host. Ending the session revokes control locally.
Choose account relay when you are continuing your own work. Choose Operator when another person is helping and you need a mutual approval flow with session-scoped control.
Design a remote-safe task
Before leaving the desktop, make the task recoverable. Save important files, confirm the active project, stop any dangerous pending command and check that the remote session can identify the right machine.
When working from a phone, prefer review, direction and small approvals over intricate unsupervised changes. A narrow screen makes it harder to inspect a large diff or catch a misleading browser state. The underlying engine is capable, but the review surface affects human judgment.
For a scheduled job, remote access is not required merely because you are away. Temporal can dispatch the schedule to the connected desktop. Remote access is useful when you want to inspect the result, intervene or continue the chat.
What not to promise
Do not describe the web experience as “cloud execution,” “no install” or a second place where terminal, files and Git run independently. Do not promise that tasks continue when the desktop is off. Those claims erase the architecture that protects continuity.
The stronger and more accurate promise is that the machine remains yours. The remote surface lets you reach it without creating a divergent environment.
Ask Upfyn
Prepare this project for remote continuation. Confirm the active desktop and project, summarize the current task and Git state, identify actions that will still require approval, and do not start any new work until the remote session is connected.