Code, Git & files

Open the worktree menu and choose New worktree. Describe what you are working on; Deska suggests a branch name and adds a number when the name is already used. Expand Branch to edit it. Details explains what gets copied, how setup runs and where the new folder goes. Start from selects the branch whose latest commit will be copied. Uncommitted changes stay in the original checkout. Start fresh opens a terminal; Copy panels names the source and copies only supported primary panels, excluding chats, nested canvases and extra tabs. Run project setup shows the detected command before running it in a new terminal. Create and open takes you to the new worktree. No agent starts automatically.

Checks groups the pull request title and branch direction above its check runs. Failures appear first; the merge action and its blocking reason follow the results, with conversation below. Explorer, Source Control and Checks share the same no-folder card, icon and Open folder action. Empty states keep the next action together with its explanation, and the first lookup shows a loading skeleton. Narrow panels wrap check names and statuses without hiding actions.

The editor panel is built on Monaco, the same editor that powers VS Code, with a file tree on the left and a tab bar across the top. Click a file in the tree to open it; tabs show a dot when there are unsaved changes.

Enlarge screenshot

• Preview vs. pinned tabs: a single click opens a file in a temporary (italic) preview tab; double-click to pin it. The tree keeps the open file selected and scrolls to it as you switch tabs.
• Resize the sidebar: drag its right edge to make it wider or narrower. Keep dragging left past the narrowest width and it closes, leaving the whole panel to the code; drag back before you let go and it stays open. Double-click the edge for the default width. The width is the same in every editor panel and Deska remembers it. The sidebar button at the start of the tab bar shows or hides it at that width.
• Search across the project: the sidebar has two tabs, Files and Search. Press Cmd/CtrlShiftF from inside a file to open Search with your selection (or the word under the cursor) already typed. Results group by file, every match with its line marked and numbered; a click opens the file with the match selected, a double click pins the tab. The three switches next to the field are match case, whole word and regular expression (Cmd/CtrlAltC, Cmd/CtrlAltW, Cmd/CtrlAltR). Include or exclude paths reveals two glob boxes (src/**, *.ts) and a Use ignore files checkbox that honours .gitignore and skips node_modules, dist andbuild. Files with unsaved edits are searched as you see them, not as they are on disk. Arrow keys walk the results, Left folds a file, Enter opens, Escape returns to the field. Find and replace opens the replacement field: every result row then shows the old text struck through and the new text after it, with a Preserve case switch so Needle becomes Thread. Replace one match from its row, a whole file from the file row, or everything with Replace all (Cmd/CtrlEnter in the field), which asks first. Files with unsaved edits are changed in the editor, where you can undo; the rest are written to disk after each match is checked again. In a regular expression, $1 refers to a capture group. Three chips under the field limit the search to what only Deska knows: Changed files (what git says changed), Agent touched (files an agent thread edited) and Open tabs; right-click a folder in the tree and choose Search in Folder to limit it to that folder. Up arrow in the field walks your earlier queries. The notebook’s Explorer page has the same Files and Search tabs. Once a search settles, Ask Dex about these opens Dex with the result list already written and the editor attached as context, so you only add what you want done; Open in a new panel copies the search into a fresh editor panel on the canvas so the list stays next to your work. While a search is open, the file in the editor shows its matches with a light wash and marks in the scrollbar, and F4 / ShiftF4 step to the next or previous match without leaving the buffer. Your switches, patterns and scope are remembered per project; the query itself is not.
• Find in the tree: the filter box above the tree matches file names and file contents. A content hit shows the matching line with the words you typed marked and its line number; opening it lands the editor on that line. Press the down arrow to walk the hits and Enter to open one. Escape clears the box; press it again on the empty box to return to the editor.
• Save with Cmd/CtrlS. Saving an untitled buffer prompts for a location. Format on save is on by default and tidies each file as it saves; turn it off in Settings → Editor, under Saving. Closing an editor with unsaved changes asks first; its Save writes every file with changes in that editor, including tabs you are not looking at, then closes it. If a file cannot be written, the editor stays open with your changes and a bar says why, with Try again.
• Images, video and audio open as a preview in the editor tab instead of as text. An image fits the panel without being enlarged, over a checkerboard where it is transparent; click it or press Actual size to see it pixel for pixel.Copy image puts the picture on your clipboard (PNG and JPEG as they are, other formats as PNG); right-click it for the path, or press Cmd/CtrlC once you have clicked it. Video plays with the usual controls and audio in a small player, and the footer shows the dimensions, length and size. An SVG opens as the picture, with Source one click away in the tab bar. Files stream from disk, so a long recording seeks without loading whole; above 2 GB the tab says the file is too big to open. A preview reloads when the file changes on disk, so a screenshot an agent rewrites shows its new version. On a Deska Cloud computer or one running deska-agentd, previews open files up to 100 MB. Local PNG, JPEG, GIF and WebP images also open outside your workspace up to 10 MB, when Deska can read them. Reopen these external previews to see later changes to the file. Archives, fonts and databases show what they are instead of unreadable text, and PDF and Word files open in their own viewer.
• Reading Markdown: .md and .mdx files open as a rendered page. The switch at the right end of the tab bar picks Source, Split (the source beside the page, scrolling together; double-click a passage to put the cursor on its line) or Preview, and Cmd/CtrlE flips between the page and its source. Each file remembers its own view; choose what opens first in Settings, Editor, Markdown opens in. The selected view always shows its name; wider panels label all three views. The page reads the way GitHub shows it: tables keep their column alignment, code is colored in your editor theme with its language and a Copy button, > [!NOTE] and the other alerts become callouts, front matter shows as properties, mermaid blocks draw as diagrams, and images next to the file appear inline (on another computer they stay links you can open). HTML in the file renders through the allowlist GitHub uses, so scripts and styles never run. An On this page outline follows the section you are reading when the panel is wide and sits behind a button when it is narrow; Cmd/CtrlF finds words in the page, ignoring case and accents. A link to another file opens it as a tab, on the heading it points at. Search stays above the page without covering the text, including in narrow panels. Press Escape from any search control to return to reading. Opening the outline focuses the current section; choosing a section returns keyboard focus to the page.

  Enlarge screenshot

  

Source Control uses one Changed files accordion for staged, unstaged and untracked files. Each file appears once and shows its staging state, status and line counts. Stage all includes modified and new files; Unstage all removes files from the index. Click a file’s row to review its diff; its Discard, Stage and Unstage buttons act on the file without opening it. For partly staged files, the Partly staged link opens the staged diff while the rest of the row opens the remaining unstaged changes.

Enlarge screenshot

Switch between Changes and History to give each list the full content area. Changes groups every file in one Changed files accordion, with staging states, directory paths, persistent line counts and a Stage all button for modified and new files. The commit area labels the message and shows how many files are staged. Switching views preserves your draft. History shows commit titles and dates; expand a commit for its author, full title, hash, references and changed files. Show older commits loads more history.

Under the header, a sync strip tells you what is still outstanding between this checkout and its remote, and carries the button that resolves it: 3 commits to push with a Push, my-branch is not on origin yet with a Publish branch, or 2 commits to pull with a Pull. A branch that has drifted both ways names both halves and offers Pull first. When there is nothing outstanding the strip is not there at all.

A commit box sits at the bottom. Write a message and press Cmd/CtrlEnter (or click Commit) once something is staged. Committing on its own is fine: once it lands, a Push now button appears right under the box, so you never have to go looking for a way to send the commit up. Amend last replaces the previous commit instead of adding one and pre-fills its message, and it works with nothing staged when all you want is to reword.

In the header, Pull only appears when there is something to pull from, Push counts what is waiting (Push 3) and reads Publish branch while the branch has no upstream yet, and a pull-request or merge-request chip can appear beside them when your branch has one open.

The canvas Git panel keeps the older three-tab layout: Changes, Log and Branches, with the same header, sync strip and commit box.

Source Control, worktrees and your agents’ commits run on Git. Cloning from GitHub, pushing to it and opening pull requests go through the GitHub CLI (gh). Windows comes with neither, and a Mac gets Git with Apple’s Command Line Tools. When one is missing on the computer in front of you, Deska says which one and installs it for you:

• In Tools & accounts, the GitHub row reads Git is not installed or GitHub CLI is not installed, and Set up opens three steps: install Git, install the GitHub CLI, sign in to GitHub. Each step shows the command it runs before you press anything.
• Source Control on a computer without Git says Git is not installed on this computer and offers Install Git. It turns back into Source Control by itself once Git answers.
• The Finish setting up card on the desk adds a Git is not installed row, and Clone from GitHub offers Set up GitHub when the GitHub CLI is missing.

On Windows, Install runs winget install in the background, and Windows may ask for permission first; the step shows its progress, and why when it fails. On a Mac, Install Git opens Apple’s own installer window, and the GitHub CLI installs with Homebrew in the background. Without winget or Homebrew, and on Linux, the step opens the download page instead (git-scm.com or cli.github.com). Every step checks again on its own, so you never restart Deska to see the change.

Two of the small chores around a commit can be handed off. A Generate button in the commit box drafts a message from what you have staged, and the new-branch form turns a plain-language description (“fix the flaky upload retry”) into a branch name in your repository’s style.

Both run only when you click them, never in the background, and both leave the result editable, so it is a first draft rather than a decision. The staged diff is read where it lives and only the drafted text comes back.

The Commit button is a split button. Its menu chains the steps you almost always run together, then streams the run back to you step by step so you can see exactly where it got to:

• Commit & Push, which becomes Commit & Publish branch when the branch has no upstream yet.
• Commit, Push & Pull request, which runs the same two steps and then creates the request through your forge’s CLI. On a GitLab remote the entry reads Commit, Push & Merge request.

The entry is named in your forge’s own vocabulary. Where Deska cannot act, it stays visible but disabled with the reason attached: no remote at all, a forge Deska does not drive, or the forge CLI not installed. On GitLab the entry notes that Deska cannot create merge requests there. Today GitHub is the forge Deska can complete the flow on, through the gh CLI.

The File Explorer panel is a file browser, not a project tree. It opens on the folder your worktree is checked out at and goes anywhere from there: into a folder, back out of it, and above the project, across the whole disk.

• Double-click a folder to open it. The folder name in the toolbar is a menu of every folder above this one, and the path bar along the bottom walks back out one click at a time.
• Three views. Icons (with previews for images), a list with sortable Name, Date Modified, Size and Kind columns, and columns for walking several levels at once. Each panel remembers its own.
• Places down the side. Home, Desktop, Documents, Downloads, Applications, your open projects and any mounted volume. Right-click a folder to add it to Favorites.
• The keyboard works. Arrows move, Enter opens, Cmd/CtrlUp or AltUp goes to the enclosing folder (so does Backspace on Windows and Linux), Cmd/Ctrl[ and Cmd/Ctrl] or AltLeft and AltRight are back and forward, Cmd/CtrlA selects the files, Cmd/CtrlBackspace asks to delete the selected ones, and typing jumps to a name. A plain Backspace or Delete never deletes a file or closes the panel.
• It still knows about Git. Inside a repository, file names carry the same status letters (modified, untracked, deleted, conflicted) the rest of Deska uses.
• Right-click for the full menu: new file or folder, rename, duplicate, copy, paste, delete, open in a terminal, open as a project, or reveal in your system file manager. Hidden files are a toggle in the view options.

1. Open a file from the file explorer and make your edits in the editor.
2. Save with Cmd/CtrlS.
3. On the notebook’s Source Control page (or the Git panel’s Changes tab), click the file to review the diff, then stage it.
4. Write a commit message (or generate one) and press Cmd/CtrlEnter.
5. Push from the Git header, or use the Commit split button to commit, push and open the pull request in one run.

Diffs are read-only and side by side: original on the left, your working copy on the right, additions in green and removals in red. To edit, open the file normally instead of through the diff. Where the diff appears depends on where you clicked:

• From the file tree inside an editor panel, the diff opens as another tab in that same editor, marked as a diff in the tab strip. Your other tabs stay exactly where they were, and a path is either a normal tab or a diff tab, never both.
• From the Git panel, the diff opens as its own editor page in the notebook on the right, titled after the file with Staged Diff or Working Diff.

From the notebook’s Source Control and Explorer pages, the diff opens as a stop inside that same page rather than a docked editor, so the review stays on the notebook’s own trail.