Braide includes a built-in file browser and code editor so you can inspect and modify files in the session's worktree without switching to an external editor. The browser opens as a docked panel on the right, and opened files are presented as tabs alongside a non-closeable Session tab — so you can flip between the agent conversation and any number of files while keeping everything mounted and live.
Click the folder icon in the session header toolbar (between the reset button and the GitHub panel button) to toggle the file browser panel. The icon is a single filled folder glyph — the same visual used for folders inside the browser tree itself — so the toggle reads as "show folders" at a glance.
When the panel is open, the toggle button is highlighted with the accent colour to make the active state obvious; when closed, it sits muted among the other toolbar buttons and picks up the standard hover treatment.
The panel slides in from the right, to the left of the GitHub panel. Both panels can be open at the same time.
The tree is rooted at the session's worktree — you can only navigate within it; there is no way to traverse above the worktree root.
Files shown match what git ls-files --cached --others --exclude-standard returns, so you see tracked files plus untracked files that are not covered by .gitignore. Directories that contain only ignored files are hidden.
Drag the vertical handle on the left edge of the file browser panel to resize it. The panel has a minimum width (matching its default size) and a maximum of 50% of the session view's width, so the session content always retains at least half the available space.
When one or more files are open, a tab bar appears above the session content area. The bar contains:
Clicking a file in the browser:
Click any tab to make it the active one. Each file editor is kept mounted while you switch between tabs, so unsaved edits, scroll position, and cursor location are preserved.
Close a file tab via either:
Closing the active tab activates the next-right tab, falling back to the previous tab, and finally to the Session tab if no file tabs remain. Closing a file with unsaved changes triggers the unsaved-changes confirmation.
The Session tab has no close button — the agent session is the root of the view and cannot be dismissed from the tab bar.
Drag a file tab horizontally to reorder it. While dragging:
The Session tab is fixed at position 0 and cannot be dragged or displaced by a file tab drop.
When there are more tabs than can fit, the tab bar scrolls horizontally — tabs keep their natural width and the scroll container ensures none are squashed or ellipsised prematurely. A tab label is capped at 16rem to guard against pathologically long filenames.
Switching to a file tab shows the editor for that file. The editor:
Dockerfile and Makefile).⌘F / Ctrl+F inside the editor) immediately.At the top of each file's editor there is a small toolbar showing:
●) when the editor has unsaved changesBecause the Session tab and every file tab are mounted simultaneously, any in-progress agent activity, streaming output, and terminal state keeps running while you are viewing or editing a file, and is immediately up to date the moment you flip back to the Session tab.
The editor shows uncommitted changes relative to the last commit (HEAD) as coloured markers in the line gutter, overview ruler, and minimap, mirroring the pattern VS Code uses for its source-control indicators.
As you type — or as the agent writes to files that are open in a tab — the markers update against the HEAD baseline, giving you an at-a-glance sense of which lines differ from the committed version:
The same colours appear in the overview ruler (the narrow strip on the right edge of the editor, next to the scrollbar) and minimap, so large changes are visible at a glance even in long files.
When a file tab opens, the editor fetches both the working-tree contents and the committed version at HEAD (via git show HEAD:<path>). The diff is then computed client-side every time the editor buffer changes, so the markers always reflect the current buffer — including unsaved edits — rather than what is on disk. This gives you a live preview of what git diff will show once you save.
If the file is untracked (not yet added to git) or the session's working directory is not a git repository (for example a scratch session not backed by one), the baseline is treated as empty and every line shows as an addition. That correctly represents the diff you would see once the file is first committed.
For pathologically large diffs (more than ~2.5 million cells in the line-diff table, roughly equivalent to a multi-thousand-line rewrite) the editor falls back to a single bulk "modified" hunk rather than per-region markers, so the editor stays responsive on huge files.
The ● dirty indicator in the editor toolbar and on the file tab tracks unsaved edits since the last load or save — it clears whenever you save. That is distinct from the gutter diff markers, which track differences against HEAD regardless of whether they are saved yet:
● dirty indicator lights up.● indicator clears, but gutter markers remain as long as the saved content still differs from HEAD.Note: the HEAD baseline is captured when the tab opens and is not refreshed while the tab is open. If you commit, amend, reset, or check out another branch from a terminal during an editing session, reopen the file to pick up the new baseline — the dirty indicator and the save flow continue to work correctly in the meantime, they just reflect the old baseline in the gutter.
The gutter markers described above are always on while the plain editor is active, but sometimes you want a full diff view of the file against HEAD. The toolbar includes a diff-view toggle (two-pane icon, next to the save button) that cycles the editor between three states:
git diff presents it. The toggle icon changes to a single framed document.Clicking the toggle advances to the next state; clicking again from inline returns to plain.
In both diff modes:
⌘S / Ctrl+S, the unsaved-changes indicator, and conflict detection all continue to work exactly as in the plain editor.The baseline is fetched once when the tab opens (same as for the gutter markers), so the diff always compares against the HEAD snapshot at that point — not against what is currently on disk. Reopen the file to pick up a new HEAD.
For untracked files or files in scratch sessions (where there is no git baseline) the toggle is disabled with a tooltip explaining why — showing the entire file as "added" in a diff view is not useful.
The selected view mode is persisted in session metadata and applies to every file tab in the session, so reloading the app or switching sessions keeps your preferred view.
Save the current file with either:
⌘S / Ctrl+S shortcut while the editor has focusSaves are atomic writes of the full file content to the worktree path. The file on disk is replaced with exactly what you see in the editor — trailing whitespace, final newline, encoding (UTF-8), and all. There is no auto-save, no create/rename/delete, and no live reload if the agent modifies the open file (those behaviors are intentionally out of scope for this release).
Closing a file tab (via either close button) while that file has unsaved edits opens a confirmation dialog asking whether to discard the changes or keep editing. This prevents accidentally losing work. Switching away from a dirty tab does not prompt — the edits stay in memory and the dirty indicator stays on the tab, so you can return and save later.
The agent running in the same session can modify the file you are editing. To avoid silently overwriting the agent's work, the editor tracks the file's modification time (mtime) at load and re-checks it on save.
If the file on disk has changed since you opened it, the save is rejected and a conflict dialog opens with three choices:
The mtime check uses a ~1ms tolerance for filesystem precision, so ordinary saves of a file you are the only editor of never trigger a conflict.
The file browser and tab state are persisted per session to the session's metadata file, so switching sessions in the sidebar — or reloading the app — restores everything as you left it:
When you click a session in the sidebar, the state is seeded synchronously from the sidebar's cached session data, so the tab bar and browser appear on the first paint rather than flickering in after a meta fetch completes.
Contents of unsaved edits are not persisted — only which files had tabs open. Reopening a session loads each file's current on-disk contents into its tab.