A project is a folder on this computer. You add a folder you already work in, or clone one from Git, and the app treats it as the place where work happens: the agent reads inside it, writes inside it, and reports what it changed.
Add a folder you already work in
Open Projects and choose Add project. Pick the folder that holds the code. The app opens that folder where it lives, and the project stays a reference to your own directory rather than a copy of it.
The first thread opens as soon as the project is added, so there is nothing to configure between choosing a folder and starting work. The project row in the sidebar carries its threads, and hovering the row offers a new thread in the same project.
Clone from Git
Clone repository takes a Git URL and adds the repository as a project. Connecting GitHub is what lets the app clone, push, and open pull requests for you, so a private repository needs that connection first.
Whichever way a project arrives, it ends up the same kind of thing: a folder, a list of threads, and a record of what each run did.
Each project keeps its own threads, files, and runs
Threads belong to the project they were started in. So do the conversation history, the files the agent read and wrote, and the runs that produced the changes. Two projects never share a thread, and a conversation you had in one folder does not follow you into another.
That separation is the point. A project is the boundary for what an agent may touch, and for what you review afterwards.
Threads gather every project conversation
Threads is the second stop on the rail. It shows every conversation you had in every project in one timeline, so you can return to work without remembering which folder it lived in.
This view's actions narrow the timeline to the projects you want and search across every conversation. A conversation needs a project, so a new thread is created from a project rather than from here.
Chats need no project
Chats is where a conversation lives when it belongs to no folder. A chat keeps its own history, model, and attachments, and nothing you ask there lands in a project you are working in.
Use a chat for research, a question about a snippet, or a second opinion that should not touch a repository. When the work does belong to a project, start a thread instead.
Switching views keeps each view's place
The rail switches between Projects, Threads, Chats, Assistant, and Browser. Switching is instant, and each view keeps where you left it: the same project, the same thread, the same scroll position. A gold square marks the view you are in.
The header's arrows walk back and forward through everywhere you have been, view changes included. A wrong turn costs one step to undo.
The bell
A finished run, a question waiting on you, and work that needs review each raise their own entry on the bell. Every entry names the project and the thread it came from, and opens straight back to where the work stopped.
That is what lets a long run go unwatched. You can leave the window, work somewhere else, and return when the app reports that something needs you.
Search
Search belongs to the header, beside the view's own actions, and it looks at what the current view is showing. In Threads it covers every conversation; in Projects it narrows the project list.
Runs that touch the same files
Two runs that write to the same files can get in each other's way. A project can give a run its own worktree, so each change has its own checkout and its own branch, and the changes can be reviewed and merged one at a time.
For everyday work, one thread at a time in the project folder is enough. Reach for a separate worktree when the work is large enough that you want two changes in flight.
Next
Getting started covers the first four moves, Agents covers the models behind a thread, and the composer covers the decisions you make before sending.