Chat, Work and Code in one desktop window

The SynapseX Desktop title bar has a row of mode pills that switch what the window is showing. This page explains what each one gives you and when to use it, so you can draft an approach in the chat experience and then have the agent implement it in your open project without leaving the app or authenticating a second time.

What are the title-bar modes?

There is a fourth pill, Labs. It opens an embedded page for a SynapseX area that is not generally available, so a normal account is told it is not enabled. This documentation does not cover it.

Code is the default, and it is the reason to install the desktop app. It is the only one of the three that can touch your local machine — see Work on a project with the desktop agent.

Chat and Work attach an embedded browser view over the native surface. Selecting Code detaches that view again and returns you to the local surface untouched, with your session and open project exactly as you left them.

Do I have to sign in twice?

No. The embedded views all share one persistent browser session with each other and with the sign-in you already did. One authentication covers every mode. Anything shipped to the web chat app also appears in these modes without you reinstalling anything.

Which mode should I use?

• Code — anything that touches your repository: reading and editing files, running commands, reviewing diffs, git work.
• Chat — a quick question where you want the chat composer’s conveniences, such as file attachments or voice input, rather than a coding session.
• Work — the chat app’s workspace pages, including Skills. See Custom skills.

Everything documented in the SynapseX Chat section applies unchanged inside the embedded Chat and Work modes — they are the same application, with the same models, limits and settings.

A concrete example: draft in Chat, build in Code

1. Click Chat in the title bar. Describe the problem in plain language and ask for an approach rather than code, for example:

   I need to add a --version flag to a shell script and document it in the
   README. What is the cleanest way to read the version from package.json in
   POSIX sh, and what should the README section look like?

2. Read the answer and settle on the approach you want.

3. Click Code in the title bar. You are back in your open project with the local agent, and the embedded view is gone.

4. Start a session (Shift+Cmd+S on macOS) and give the agent the decided approach as a specific instruction:

   Add a --version flag to scripts/build.sh that reads the version from
   package.json using the approach we settled on, then add a Usage entry for it
   in README.md. Do not change anything else.

5. Read the diff in the review panel and check what changed.

The value of the split is that the thinking happens where a conversation is cheap and no files are at risk, and the editing happens where you get a permission prompt before any command runs and a diff of every file the agent touched.