# Organizing threads A thread is one conversation and its continuing work history inside a project. Use separate threads for separate questions or outcomes so their instructions, results, and follow-up work remain easy to find. You can run several threads in parallel; use an isolated worktree when simultaneous tasks should not edit the same project files. Pin a thread from its context menu to keep it in the pinned section above your active work. `mod+shift+p` pins or unpins the thread you have open. Pinned threads are shown independently of their project, including when you connect to more than one environment. To require confirmation before unpinning, enable **Settings → General → Unpin confirmation**. The confirmation applies to the sidebar controls, thread menus, and the `mod+shift+p` shortcut. On web and desktop, **New thread** opens the project picker when you have more than one open project in the default or project-grouped sidebar. Archived projects don't count. **Shift-click** to start in the current project, or use a project's own new-thread action. A new thread carries your model and mode selections, unless the destination project has its own model default. Its branch and workspace mode come from your configured defaults. To continue in an existing worktree, use **New thread in this worktree** from the branch toolbar. Pinned threads still move to **Settled** when they become inactive. They also move when their pull request merges if **Auto-settle merged threads** is enabled. Each server owns its automatic settlement settings and checks them even when no web, desktop, or mobile client is connected. By default, Scient settles threads after seven days without activity; settling when a pull request merges is available but off by default. An eligible idle thread also settles when its pull request closes. An open pull request blocks inactivity settlement. Active work, pending input, and live background work keep the thread active. Scient settles from a closed or merged pull request only when its timestamp is not older than the user's latest activity. If that timestamp is not available, the inactivity rule still applies. A manual un-settle also keeps the thread active. **Settled** lists threads by when their work finished, newest first. A thread you settle yourself sorts by the moment you settled it. A thread that settled on its own sorts by its last message or turn, not by when the server noticed it was inactive. Scient keeps ordinary work attached to a project. Development scratch conversations use the candidate-owned isolated scratch workspace; they do not restore the retired Quick Chat workspace. Change these rules in **Settings > Threads**. The change is written to every connected environment whose server supports shared settings. An environment that is offline or needs a server update keeps its old value and does not appear in mismatch warnings. When a connected environment whose server supports shared settings holds a different value, **Settings > Threads** shows a warning that names it. Choose **Apply to all** to write your current values to the environments named in the warning. The same applies to the new-thread workspace mode and the source control writing style. To send the same prompt to several models on web or desktop, **Shift-click** models in a new thread's model picker to add or remove them. A regular click returns to a single model. Choose a base branch and send. Each selection starts a separate thread and worktree while you stay in the new thread composer. This requires a Git project. On mobile, **New thread** starts in the current thread's project, or else in the last project you opened or chose on that device. If neither is available, the project picker opens. Turn off **Settings → General → Use last project** to choose a project every time. ## Keep the computer awake In the desktop app, **Settings > Maintenance > Keep computer awake** stops this computer sleeping while its threads work. It's off by default. To cover one thread without the setting, right-click it and choose **Keep computer awake until done**. That choice ends by itself about a minute after the thread and its subagents finish, and it covers the thread's next run if nothing is running yet. Work means a run or a background command, including one the agent left running, such as a dev server, so stop those to let the computer sleep. The computer can sleep while a thread waits for an approval, an answer or a secret, watches a pull request, or waits for a usage limit to reset, even if it has a background command running. A run that has lost its provider session stops counting, and a process the agent detached itself, such as with `nohup`, isn't seen at all. The screen can still turn off, and closing the lid or choosing Sleep still puts the computer to sleep. Windows laptops with Modern Standby can end the request on battery a few minutes after the normal sleep time. Threads on another computer keep running while this one sleeps, so they aren't covered, and neither are threads in a WSL backend yet. ## Pin and reorder threads A settings change affects future settlement and does not reopen a settled thread. Settings saved by older clients on one device no longer control this behavior. When you un-settle a thread, it returns to the top of the active list so you can find it right away. Its timestamps do not change. Other threads keep their positions. Right-click a pull request link in a thread and choose **Link to thread** to show that pull request in the sidebar. The thread settles when the linked pull request merges if **Auto-settle merged threads** is enabled. Right-click the same link and choose **Unlink from thread** to remove it. On web and desktop, unpinning, settling, snoozing, and archiving a thread each show a notification with **Undo** for five seconds. Undo restores the thread's previous state, including its pinned position, and reopens an archived thread you were viewing. Discarding an unsent draft from the sidebar works the same way: Undo brings back its text and attachments. `mod+z` triggers the most recent Undo, even from the composer; see [Keybindings](./keybindings.md#commands-with-special-behavior). On web and desktop, you can also drag files from your computer onto any thread row: the thread opens and the files are attached in its composer, ready for your next message. The same per-message file limits apply as when attaching files directly; see [Attach files](./composer.md#attach-files). On web and desktop, pinning or unpinning a thread keeps the sidebar at your current scroll position instead of following the thread to its new place in the list. Pinning does not prevent automatic settlement. Settling a thread removes its pin. On web and desktop, drag a thread between sections to change its state. Drag a thread up into the pinned section to pin it at the spot you drop it; drag a pinned thread down into the active list to unpin it. Dragging a thread onto the **Settled** header settles it, and dragging a settled thread into the active list un-settles it. A snoozed thread can be dragged out of the snoozed shelf, which wakes it, but threads cannot be dragged into the shelf because snoozing needs a wake time. Dragging a pinned thread out of the pinned section does not ask for unpin confirmation. Pinned and active boundary labels appear only while dragging, without moving the rows. The other rows slide aside to show where the thread will land. When you cross into another section, the dragged thread shows the action the drop performs, with its icon: **Pin**, **Unpin**, **Settle**, **Un-settle**, or **Wake**. Its status and hover actions hide during the drag. A pinned thread keeps its pin only while it stays in the pinned section; once it leaves, the badge takes over. Reordering within the same section shows no badge. When there are no pins, drag to the top edge to pin a thread. Section labels stay readable for the whole drag, and the section the thread is over takes the accent color. Section labels also identify empty sections and a collapsed settled shelf. Drag within the pinned or active section to change its order. Other rows slide aside to show the spot where the thread will land. Drops into either section keep the position you choose. On mobile, open a thread's menu and choose **Arrange threads**. Drag a handle within or between **Pinned** and **Active** to reorder, pin, or unpin. Drop onto the **Settled** divider to settle a thread. The dragged card shows the action before you release it. Expand **Snoozed** or **Settled** to drag a parked thread back into either live section. Each drop saves; close the sheet to return to the thread list. **Move up** and **Move down** are also available in the thread menu. The server saves the order, so it survives a refresh and appears on your other connected devices. On web and desktop, the list also animates section changes made with thread actions such as **Pin**, **Settle**, and **Snooze**. These transitions respect your system's reduced-motion preference. While dragging, rows follow the insertion gap without replaying a second transition after the drop. New threads appear above the active threads you have arranged. Settling clears a thread's active position, so using **Un-settle** returns it to the top. Pinning and snoozing preserve its active position until you move it again. Automatic placement can bring active threads near the top without changing this saved manual order, as described below. The settled shelf continues to use the finished-work order described above. If dragging is unavailable for one environment, update the Scient server running in that environment. Pinned and active reordering require server support. Threads from older servers keep their default order until the server is updated. To generate a fresh title from the conversation, open a thread's context menu and choose **Regenerate title**. While Scient is generating it, the action reads **Regenerating…** and cannot be selected again. The option is hidden when the connected environment needs a server update. To change how titles are written, add **Thread title instructions** in **Settings → Threads → Text generation**, under Advanced, such as a length limit or an identifier to put first. They apply to new and regenerated titles. Select a project to give it its own instructions. An empty project value disables extra instructions for that project; clearing its override restores the environment value. Older Scient apps cannot see project title instructions, so changing or resetting the project's other settings there keeps them. Agents connected through Scient can use the same server-owned metadata workflow to rename a thread, regenerate its title, or link and unlink a pull request. These changes appear on web, desktop, and mobile without requiring the originating browser to remain open. ## Keep active threads near the top **Settings → General → Organization → Keep active threads near the top** is on by default. One switch controls both the default Pinned and Active sidebar and Sections view. It applies to the unpinned inbox in the default sidebar, and separately inside each section, including General. An existing off preference stays off. Working, Monitoring, unread Done, approval or input requests, failed sessions, and unread Woke threads share one upper group. There is no priority between those states: a thread joining the group goes below its existing members, above ordinary inactive threads. Switching from Working to Monitoring or Done keeps its position. Pins remain above both groups; Snoozed and Settled keep their existing shelves. Opening a Done thread clears its unread status as usual but keeps its place while you read. Three seconds after you leave, an inactive thread moves to the first inactive position, below the upper group. Reopening it restarts that delay; new work cancels it. Other newly inactive threads can subsequently land above it. You can still drag threads within the inbox, within or between sections, and move whole sections. A drop keeps the place you choose, with one limit: active work always gets the top back. | You drag | It stays there | | -------------------------------------------- | ----------------------------------------------------------------------------------- | | An active thread within the upper group | Until you move it again. | | An inactive thread among inactive threads | Until you move it again. | | An inactive thread above active threads | Until another thread becomes active; the upper group then forms above it again. | | An active thread down among inactive threads | Until it stops being active. Meanwhile, newly active threads still join at the top. | For example, if you drag X above a working A, X stays there until B starts working; then A and B sit above X. If you drag a working A to the bottom, a later working B still goes to the top while A stays where you put it. Movement pauses during a drag or native context menu. When you are connected to several machines and one is offline or catching up, only that machine's threads hold their last known places; threads on the other machines keep moving. Its threads are rechecked when it is back. Turning the setting off reveals the saved manual order and cancels pending movements. Manual moves made while it was on remain saved. Turning it back on groups current active threads in saved order, then follows subsequent transitions. The switch and automatic positions belong to this client; section membership and manual order remain shared through the server. Refresh preserves local positions, and revalidates current status before moving threads. Filtering projects or collapsing a section never counts as reading or removes a thread from its remembered position. The two views remember their automatic positions separately. When **Working section (beta)** is on, the default sidebar uses that feature's own ordering instead. Automatic placement still works in Sections view. Search results keep their search order; the mobile app keeps its existing behavior. ## Start a new thread **New thread**, the row directly below search, starts a thread. It first asks which project to use, with the current project first, so **Enter** starts there. Choose **No project** to start in a scratch folder on the current machine. **Add project** sits above **No project** at the bottom of the picker and runs the usual Add project flow before opening a new thread in that project. When there are many projects, only the projects scroll; both actions stay visible. **⌘N** works the same way. To skip the list and start in the current project, **Shift+click** New thread or press **⇧⌘N**. The small dashed chat button to the left of **New thread**, separated by a vertical line, starts a chat without a project directly. Its tooltip is **Chat without a project**. It appears when the current environment offers scratch conversations. ### Threads without a project **No project** opens the usual composer. Before sending, its project picker lets you switch to a real project without losing the draft. The sidebar row and Add project flow stay the same. Scient creates one internal scratch project per machine and a separate plain folder for each conversation under its data directory. Files, Sources, Documents, and Compute use that conversation's folder. Scratch conversations do not have Git branches, checkpoints, or turn diffs. Deleting a conversation keeps its folder; moving a started scratch conversation and its files into another existing project is not yet supported. When the work grows into something real, pick **Turn into project** from the thread's menu. The thread's folder becomes a project where it is, so nothing moves and the agent keeps working in the same place. Other threads in that folder move with it. Rename the project in its settings, and use **Initialize Git** to get branch and diff controls. The option is available on a connected machine whose configured scratch location is outside Git. Git does not need to be installed: the server verifies its own scratch folders through canonical filesystem paths and repository markers. Other detection or permission failures leave the option unavailable. Dev candidates keep their profile inside the worktree but use a separate persistent scratch location outside Git. ## Group threads into sections On web and desktop, sections let you group related threads by topic, such as **To look at** or **Research**, across projects. A thread belongs to at most one section. Sections only organize the list: filing a thread never pins, settles, snoozes, or reorders it, and does not count as activity. Right-click a thread and choose **Move to section…**, next to Pin, Settle and Snooze, to file it. A picker opens with a search field: type to find a section, then press Enter or click it. The current section is checked. **General**, which takes the thread out of its section, comes first, then the sections by name; when there are many, the ones you used most recently lead the list. If no section has the name you typed, choose **Create “name”** to make it and file the thread in one step. With one project selected, the picker lists that project's sections; searching also finds other projects' sections, under **Other projects**. A fork of a thread in a section starts in the same section. With several threads selected, **Move to section** files them together. Each move shows **Undo** in the sidebar, and `mod+z` restores the previous section. Click **Group by section** next to search to see the sidebar by section; the button stays highlighted while it is on. Click it again to return to the default Pinned and Active layout. In the Sections view: - Each section lists its pinned threads first, then the rest in your arranged order. Threads without a section, including new ones, appear in **General**, which comes first until you move it. You can drag **General** like any section, but not rename or delete it. - Snoozed and settled threads stay on their own shelves. A settled or snoozed thread keeps its section and returns to it when you un-settle or wake it. - Drag a thread to a spot in any section to file it there at that position, or onto a section's header to file it at the top of that section, including an empty or collapsed one. Only a header that the drop would change is highlighted. Drag a section header to reorder sections, or drag a thread onto the **Settled** header to settle it. Dragging never unpins a thread. - Click a header to collapse it. A collapsed section's arrow points right, and it still shows the thread you have open. A dot shows its most urgent thread state, in the project folder colors: needs you, failed, done but not yet opened, or working; a hollow ring means a thread is waiting. Hover the dot for the count of each. An open section's arrow points down and appears when you hover the header. Double-click a header to rename it. - Each header's buttons start a **New thread in section** and open the section menu, which also offers **Rename**, **Move up**, **Move down**, and **Delete section**. - With **All projects** selected, every section is listed, including empty ones, so you can drag threads into them. With one project selected, only that project's sections are listed: those holding any of its threads (snoozed and settled ones count), and empty sections created while that project was selected. A section holding threads from two projects appears under both, each time with that project's threads only. - **New section**, after the last section, adds one at the end. - Section names start with a capital letter, capitalized as you type. A first word that mixes case on purpose, such as _mRNA_ or _iOS_, is kept as written: paste it, or type it and then change the first letter back. ### Sections on several machines Sections are stored on the machine that runs their threads, so every window and connected client shows the same sections: the desktop app on that machine, the web app opened remotely, or Scient on another computer connected to it. With one machine, as most people have, this is all you notice. With more than one connected environment, such as your computer and an SSH server, each machine has its own sections: - A thread can join only sections of its own machine. The **Section** menu lists that machine's sections, and dragging a thread onto another machine's section does nothing. - While sections from more than one machine are listed, each header shows its machine's icon after the section name; hover it for the machine's name. Two machines' sections with the same name stay separate. - **New section…** for threads on several machines creates a section of that name on each. A section started from **New section** goes to the machine of the selected project; when more than one machine can hold it, the form lets you choose. - **General** holds every machine's threads without a section. Each machine keeps its own order of sections and General's place among them. **Move up** and **Move down** step over that machine's sections, and a section dragged among another machine's sections returns to its own machine's group. Before this, one section list served every environment. A thread on another environment that was filed into that list now shows in **General**; file it again into a section of its own machine. Update Scient everywhere you use it, since older versions still file every thread into one list. ### Removing empty sections To remove sections you no longer use, turn on **Settings → General → Delete empty sections** and choose how many days a section may stay empty (7 by default). It is off unless you turn it on. Each environment has its own setting: choose an environment at the top of Settings to change only its cleanup, or **All environments** to change every connected environment together. A section counts as empty when no active, pinned, snoozed, or settled thread belongs to it; archived threads do not keep a section. Adding a thread restarts the count, and **General** is never removed. Cleanup runs only while Scient is open, and a device only judges a machine's sections after it has held that machine's full thread list for a minute. It shows **Undo** when it removes a section. Deleting a section never deletes conversations: its threads move to **General**, and **Undo** on the confirmation brings the section and its threads back. If **Section** is missing from a thread's menu, update the Scient server running that thread's environment. The mobile app does not show sections yet; it keeps its usual layout. ## Fold working threads Threads that are working or waiting on work they will resume from move into a collapsed **Working** section below the active list. That includes subagents, watched pull requests, and background commands or monitors the agent says it is waiting on. A dev server or other process an agent leaves running does not keep a thread there. A thread returns to the top of the active list when it finishes, fails, or needs an approval or answer. The Working section lists the thread you last sent work to first. Pinned threads stay in the pinned section. This is off by default. Turn it on with **Settings → General → Working section** on web and desktop, or **Settings → General → Working section** on iOS and Android. Each device keeps its own choice. While this is on, the active list is ordered by when each thread last came back to you, so you cannot drag or move threads within it. Your saved order returns when you turn it off. This belongs to the default Pinned and Active layout. Turn off **Group by section** to use it; the Sections view replaces that layout and never folds threads into a shelf. ### Group threads by project (beta) Turn on **Settings → Labs → Boring sidebar (group by project)** on web and desktop to put active threads in a folder for each project. Pinned projects come first. A project with no active threads has no folder unless it is pinned or you pick it in the project filter. An archived project's folder comes last and shows only while it has active threads. Click a folder to open or close it. A closed folder shows how many threads it holds, and a dot when one of them needs you. Use the pen button on a folder, or right-click it, to start a thread in that project. Pinned threads stay above the folders, and Snoozed and Settled stay below them. In this mode you can drag a thread onto the composer to mention it, but not within the sidebar, and the Working section is off. Each device keeps its own choice. ## Settle finished work Choose **Settle thread** from its menu to move finished work out of the active list without deleting the conversation. **Un-settle thread** restores it to active work and prevents automatic settlement until new activity resumes the usual rules. Manually settling an idle thread dismisses unanswered async questions without sending an answer or restarting the agent. Settling also closes the thread's terminals that wait at an idle prompt, and keeps their output. A terminal that runs a command, such as a dev server, stays open unless its action has **Stop this action when the thread settles** enabled in Settings > Projects > Actions. You can also set `"stopOnSettle": true` on a `t3.json` action and import it there. Start the command through that action so Scient can stop its terminal and child processes. Commands started through an agent's own shell tools are managed by the provider. If reordering is unavailable for one environment, update the Scient server running there using the version guidance shown in the app. Older servers can still pin and unpin threads, but do not understand synced ordering; their pinned threads keep the default newest-first order below the ones you have arranged. To reclaim disk space from settled work, turn on **Run in the thread's worktree when the thread settles** for one of the project's actions, or set `"runOnSettle": true` on a `t3.json` script, for example `cargo clean`. It runs each time a thread in its own worktree settles, manually or automatically, even if a terminal there still runs a command such as a dev server. Threads in the project's main checkout skip it. Its terminal closes when the command succeeds and stays open when it fails. On web and desktop, press a thread's **Settle** button and drag up or down to settle every thread in that section between it and the one you release on. The **Un-settle** and **Wake** buttons work the same way in their sections. Press `Escape` while dragging to cancel. By default, environments settle inactive threads after seven days and settle threads whose pull request merged. A closed pull request can also settle an idle thread. An empty thread's inactivity counts from when it was created. Work in progress, pending questions or approvals, and background work the agent is waiting on prevent automatic settlement. An open pull request does not prevent inactivity settlement unless you turn on **Keep threads with a PR** in **Settings → Threads**, but an old closed or merged pull request does not settle work you resumed after it closed. Only your own messages count as resuming. A turn that finished background work or a pull request watch starts on its own does not. To keep one thread out of the settled shelf no matter how long it sits idle, open its menu, choose **Auto-settle behavior**, and pick **Never**. The current option is checked. Pick **Follow settings** to return to the rules in **Settings → Threads**. While those rules are off, a thread on **Follow settings** does not settle automatically either. Manual settle, snooze, and archive still work while it is set to **Never**. Change these rules in **Settings → Threads**. They continue to run when your apps are closed. On web and desktop, choose an environment at the top to change only its rules, or **All environments** to update connected environments together. Mixed values show where the selected environments disagree. Mobile applies these rules to connected environments that support shared settings. Offline environments and older servers keep their previous values. Changing a rule does not reopen already settled threads. ## Panel motion The main sidebar, right panel, and terminal drawer open and close immediately by default. Under **Settings → Appearance → Motion**, move the **Panel animations** slider above 0 ms to add motion. The duration can be set up to 400 ms. Clicking the preview replays all three panel transitions; at 0 ms, it snaps between the same open and closed states. The server finds the PR for each unsettled thread's saved branch, even when your apps are closed. Settled threads keep their saved links. Update the server if automatic branch links do not appear. On web and desktop, right-click a pull request link in a thread and choose **Link to thread** to select a different PR. Use **Unlink from thread** on the same link to return to the branch PR, if one exists. The linked pull request participates in automatic settlement. ## Find threads On web and desktop, press `Cmd/Ctrl+K` to open the command palette and search threads across connected environments by title, branch, pull request, or project. Threads you open often or recently rank higher, and for three weeks the thread you last picked for a query ranks higher when you type that query again. Threads whose messages contain all your words appear below, under **In messages**, and open at the matching message. Message search needs at least one word of three or more letters, or two for Chinese, Japanese, and Korean. On mobile, the thread list search also lists message matches and opens them at the matching message; on an iPad with a keyboard, `Cmd+K` opens the same palette. ## Environment icons When you are connected to more than one environment, every thread that lives somewhere other than the machine you are on wears a small icon for that machine at the end of its row: a server, a cloud VM, a desktop, a laptop, a Mac mini, or a Mac Studio. In the hosted web app and the mobile app, where every environment is remote, each row wears its machine so you can tell them apart at a glance. The same icon appears wherever an environment is named: the thread tooltip, the command palette, the "Run on" picker, the pull request server filter, the provider settings device tabs, and the environment lists under **Settings → Environments**. On mobile it appears in the thread lists, the archive, the new-task environment picker, and the Environments and storage settings. Servers pick the icon themselves from the hardware they run on. A Mac reports its model, a Linux machine reports its chassis type and whether it is a virtual machine, and anything without a usable signal shows a generic server. To override it, open **Settings → Sharing & access** and choose an icon for that environment; **Automatic** goes back to what the server detected. The choice is stored on that server, so every device that connects to it sees the same icon. ## Environment artwork Dev and Nightly environments can identify themselves with artwork at the top of the sidebar and in the send button. Choose **Artwork**, **Version pill**, or **None** in Settings under environment identification. Artwork is recolored to match each built-in theme. Custom themes use the **Version pill** fallback because their colors are not controlled by Scient. ## Unread answers on the app icon Scient's app icon shows how many threads have an unread answer: on the Dock on macOS, on the taskbar button on Windows, and on Linux docks that support badges. It counts the threads the sidebar marks unread, in every project, so reading a thread here or on another device lowers it, and **Mark unread** raises it again. Several answers in one thread count once. Archived, snoozed, and settled threads are not counted, nor are the threads agents start for their subagents. A queued turn starting does not clear an earlier unread answer, and stopped or failed turns do not add one. Turn it off in **Settings → General → App icon badge**. On macOS, the badge needs notification permission: macOS asks once, the first time there is something to show. If the count doesn't appear, allow badges for Scient in System Settings › Notifications. On Windows, badges must be on in Settings › Personalization › Taskbar. The badge itself sends no banner or sound. The badge keeps updating while Scient is in the background or minimized. Closing the last window pauses updates until a window is reopened; the last count remains. Quitting Scient clears it. ## Inspect agent work **Limited** means the provider stopped on a usage or rate limit. The conversation keeps the provider's explanation. Retry after the limit resets, or switch to another provider instance. Press **Resume** in an empty composer to continue a limited or interrupted turn manually. Do this when the provider reports no reset time, because nothing continues the turn on its own. Queued messages stay saved while the limit blocks the thread. They run after the continuation finishes. If the queue was held by a restart, resume it then. When the provider reports a reset time, choose **Resume at reset** to schedule a continuation. You can cancel it from the thread. Enable **Resume after usage limits** in **Settings → Threads** to schedule limit stops by default. The environment must be running when the reset arrives; it resumes overdue continuations after a restart. Stopping the thread, sending a new message, archiving, or settling it prevents a pending continuation from starting. Choose **Snooze until reset** to hide the thread until its allowance returns. Snooze and auto-resume are independent: snooze alone wakes the thread without sending a message; enabling both wakes and continues it. **Wake now** cancels the snooze. Enable **Snooze until limits reset** in thread behavior settings to snooze limit stops by default. Providers without a reset time offer manual retry and the normal snooze choices. ## Tool details On web and desktop, use **Agents** to follow work delegated to subagents. On mobile, open a subagent from its conversation card or **Agents**. On iOS layouts with an inspector, its thread opens beside the parent. Maximize it to fill the screen; close the full-screen view to return to the parent and inspector. Stop on a thread also stops the subagents it delegated to. Subagent threads started by the agent can't take messages; message the parent thread instead. When such a subagent needs an approval or an answer, the parent thread asks for it. Scient Agent groups show only their summary while collapsed. Expand a group for compact member rows, then expand a member to inspect its full assignment and any supplied result. **Open child thread** navigates to that member's child, separately from its detail disclosure. An explicitly opened group stays visible as its background children finish. Native Scient child inspection contains the assignment and result the agent actually supplied, not a reconstructed tool or thinking transcript. Missing results remain unavailable; the member row and **Agents** panel show observed progress, model and usage rather than borrowing those details from the parent. Expand a tool call in the conversation to see its full command and output. Summaries shorten shell wrappers and can still describe the latest call after it finishes; the call's own result shows its status. On web and desktop, the thread details card lists the web servers that the thread's terminals or its Claude agent started, with their ports. A server the agent started stays listed after the agent's turn ends. Select a server to open it in the browser panel. **Stop** ends the server's job and keeps the agent, the terminal, and Scient running. Stop needs terminal access to the environment and is not available on Windows. To choose what the thread details card shows, right-click the card or open **Settings → Appearance → Thread details**. Hidden rows keep their keyboard shortcuts, such as Open in editor and project scripts. **Reset to default** brings back the standard rows. ## Side chats A side chat lets you ask a question about a thread without adding to it. It starts with what the thread knows, and the thread keeps working while you ask. On web and desktop, start a message with `/side` or `/btw`, then your question. You can also open a new tab in the right panel with **+** and choose **Side chat**. The side chat opens as a tab there, with its own composer. Side chats do not show in the sidebar. Find one again under **Side chats** in thread details. A side chat works in the same folder as the thread and starts with the permissions, model, and reasoning level shown in the thread's composer, including for its first reply. Change them for an individual side chat in its composer. Later changes to the parent do not change existing side chats. To use what you learned, choose **Bring back**. The thread gets the side chat with your next message there. Bring back is available while the thread is idle. Closing a side chat you never sent a message in deletes it. To delete one you used, choose **Delete** at the top of the side chat. Deleting a thread also deletes its side chats. On mobile, a thread lists its side chats above the composer. Tap one to open it and answer its questions. ## Snooze until later To change the choices in the snooze menu, open **Settings → Threads → Snooze options**. Each option is a duration, such as 3 hours, or a time on a day, such as 9:00 PM tomorrow. A weekday means the next one after today. Menus list the options soonest first and hide a today option after its time passes. Saved with **All environments** selected, the options apply to every connected environment, and the mobile app uses them too. Choose **Snooze → Custom…** from a thread's menu to pick a date and time in your local time zone, or a duration in minutes, hours, or days. Durations start when you confirm; one day means 24 hours. On web and desktop, you can also snooze several selected threads together. Choose **Wake thread** to bring a thread back early. A snoozed thread keeps working and stays hidden until its wake time, even while its agent wakes itself for background work. It comes back early for an approval, a new question, a failed run, or a message or answer you send. You can snooze an existing question and answer when the thread wakes; the question stays unanswered.