Editor

The editor is a real editing surface, not a preview pane. It is CodeMirror 6, themed to the workbench, with an optional Vim mode; files open as tabs with dirty tracking and ⌘S saves through a workspace-guarded endpoint. Everything you can open, the agents can see — and nothing outside the workspace and its mounts is reachable by either of you.

Vim mode is a single setting that applies to every editor in the app; :w calls the app’s own save handler.

Vim mode

Turn it on in Settings → Editor, or from the command palette (⌘⇧P → Toggle Vim Mode). The choice is remembered across restarts and applies to every editor in the app — files, the workflow JSON view, and inline edit. :w is wired to the same save handler ⌘S uses, so writing a file the way your fingers already know does the right thing.

Files and tabs

The file browser lives in the activity bar and shows every mounted folder as a virtual top-level directory, expanded by default, with LatchAI’s own workspace sandbox as a collapsed root at the bottom — reachable without cluttering the view of the code you actually came to edit.

Tab behaviour follows VS Code’s grammar:

• A single click opens a preview tab, shown in italics; the next single click replaces it. Double-click a file (or its tab) to pin it.
• Tabs drag to reorder, and right-click for a context menu.
• Activating a file tab reveals that file in the tree — un-collapsing its root, expanding every ancestor, and scrolling the row into view.
• A dirty tab shows a dot; ⌘S saves the active one.

The tree also carries the Code Atlas affordances: a Maps section above the tree listing your code maps, and a 🗺 hover action on mount roots and their top-level folders that builds one.

Workflow tabs are special: they toggle between Canvas and JSON, and both views project the same draft, so a Vim edit to the JSON appears on the canvas and vice versa.

Inline edit

Select code, press ⌘K, describe the change, and the provider rewrites the selection in place. It is the smallest possible unit of AI editing — no conversation, no plan, just a transformation you can undo. Enter applies, Esc cancels, and a failed request leaves your selection untouched.

Git

The git panel is a review lens over your real repositories — deliberately not the shadow repository LatchAI uses for checkpoints.

It discovers every git repo under the workspace and your mounts (down to three levels, up to fifty repos, skipping node_modules and friends), so nested project repos are first-class rather than invisible. Pick one from the dropdown and the panel shows what its current branch changed, file by file, with per-file +/− counts.

Four modes decide what “changed” means:

Mode	Range
Auto	On a feature branch, everything since the merge-base with the default branch; on the default branch, the last commit
vs main	Always the merge-base range, whichever branch you’re on
Last commit	HEAD~1 forward
Working tree	HEAD forward — just the uncommitted work

Every mode ends at the working tree, so uncommitted edits always show, and untracked-but-not-ignored files are included as additions — an agent’s brand-new file is part of the change under review before anyone runs git add.

Clicking a file opens the repo’s review tab with both sides side by side. The panel also drafts a conventional-commit message with the configured provider, runs an AI review of the range, and commits. It refreshes itself as the repo changes on disk, with a one-second settle so a build writing two hundred files refetches once.

Status, an AI-drafted message, and a commit — against your real repo.

There is a containment rule worth knowing: every operation requires the chosen root to be the repository toplevel. A directory that merely sits inside some other repository is treated as “not a repository” for reads and refused outright for commits, so a stray git add -A can never stage a worktree you didn’t mean to touch. Discovery only ever yields directories that own a .git, so discovered repos always satisfy the rule.

Working-changes review

The review overlay can also be pointed at your current git diff for an AI review of work in progress — the same colored unified-diff surface used by review gates and chat-turn review. The result comes back as markdown findings, most important first.

Diagnostics

Rather than host a full language server, LatchAI runs your project’s own typechecker on demand and parses the output into structured diagnostics: file, line, column, severity, message. A project is detected by its tsconfig.json, and the check runs npx --no-install tsc --noEmit in that root with a two-minute ceiling.

The point of it is the check_diagnostics tool, which is what lets an agent see and fix its own type errors before it claims to be done — and it is what a workflow step means when it verifies its own edits.

Diagnostics come from the project’s real checker, not a heuristic.

Note

This is a deliberate first cut. TypeScript is the only checker wired up today — a project with no tsconfig.json returns no diagnostics rather than an error — and the results are surfaced through the tool and the /api/diagnostics endpoint rather than as gutter markers in the editor. Full LSP features (go-to-definition, hover, completions) are not implemented.

Syntax and theming

Language is detected from the file name, with the workflow JSON view naming its language explicitly. The syntax palette is applied globally rather than per language, so JSON, markdown and TypeScript are coloured by one consistent scheme — and the diff viewer shares it, which is why a file reads the same way in review as it does in the editor.