List repositories the bridge can open and which one is currently active. Call this first when you do not know what is available.

Open a local repository and return a full project brief: languages, build system, detected build/test/lint commands, module layout, git state, and the repo's AGENTS.md / CLAUDE.md instructions. Accepts an alias from workspace_list or an absolute path inside a configured root. Makes the workspace active for subsequent tool calls.

Current state of a workspace without re-reading the repository: branch, working-tree changes, recent commits, detected commands, and everything this bridge session has already changed. Use this to resume work ("continue on quantix").

Clone (or refresh) a remote Git repository into an isolated managed workspace and check out a branch. Use for work on a repository that is not already on this machine. Returns the same project brief as workspace_open. Each task gets its own workspace so parallel tasks cannot interfere.

Stop tracking a workspace. For managed (cloned) workspaces you can also delete the directory to reclaim disk. Never deletes a local workspace's files.

List files and directories. Use for orientation in an unfamiliar area of the repo. Build outputs, node_modules and .git are skipped automatically. Prefer search_code when you are looking for something specific.

Read a file as text. Returns exact file content (no line numbers by default) so it can be copied verbatim into edit_file anchors. For large files pass start_line/end_line, or use search_code first to find the region worth reading. Credential files (.env, keys, cloud config) are never returned.

Search file contents across the repository and return matching lines with file:line locations. This is the primary way to find code — far cheaper than reading files. Supports literal or regex patterns, glob filters, and surrounding context lines. Respects .gitignore.

Find files by name or glob pattern (e.g. "**/Service.java", "**/test_.py"). Use when you know roughly what a file is called but not where it lives.

Create a new file, or replace / append to an existing one. Use this for NEW files. To change part of an existing file use edit_file instead — it is safer and much cheaper than resending the whole file.

Make targeted edits to an existing file by replacing exact text. Each edit's old_string must appear exactly once (include surrounding lines to disambiguate) unless replace_all is set. All edits are applied atomically — if any anchor fails to match, the file is left untouched and you are told why. This is the preferred way to modify code.

Move or rename a file or directory inside the workspace.

Delete a file, or a directory tree with recursive=true. Deleting the workspace root is refused. Prefer deleting specific files over directories.

Create a directory (including parents). write_file already creates parent directories, so this is only needed for empty directories.

Check whether a path exists and get its size and modification time, without reading it.

Run a development command in the workspace (build tools, package managers, test runners, git, language toolchains). Commands run WITHOUT a shell: pipes, redirects, && and ; are rejected — issue separate calls instead. Only allowlisted executables are permitted; destructive commands require confirm=true. Prefer run_build / run_tests / run_lint, which pick the right command for this project automatically.

Build the project using the build command detected from the repository (Maven, Gradle, npm/pnpm/yarn script, cargo, go, dotnet, make…). Returns exit code and output with error lines preserved even when the log is long.

Run the project test suite using the command detected from the repository. Failing output is summarised with the failure lines pulled out, so you can go straight from "tests failed" to the responsible code. This is the tool to use in an implement → test → fix loop.

Run the project linter / static checks using the command detected from the repository (eslint, ruff, clippy, go vet, spotless…).

Current branch, upstream tracking, ahead/behind counts, and every staged / unstaged / untracked file. Check this before committing, and to notice user changes you did not make.

Show changes as a unified diff. against="worktree" (default, unstaged changes), "staged", "head" (staged + unstaged), or a branch/commit name to compare the current branch against it (uses the merge base). Use stat_only=true first on a large change to see which files moved before pulling in the full diff.

Recent commits, newest first. Useful for matching the project's commit-message conventions before committing.

List branches, or create / switch to one. Creating a feature branch is the normal first step before making changes, since commits to protected branches are refused.

Stage and commit changes. By default every modified and untracked file is staged; pass paths to commit a subset. Refuses to commit on a protected branch — create a feature branch first. Write the message in the style of the repository's recent commits (check git_log).

Discard changes to specific files, or unstage them. This destroys uncommitted work, so it requires confirm=true and specific paths — it will never discard everything at once.

What this bridge is allowed to do: permission level, which capabilities are enabled, which executables may run, timeouts and output limits, protected branches, and whether GitHub/GitLab tokens are configured. Check this when a tool is refused, or before planning work that needs to push.

Summarise everything done in this workspace: files changed (with per-file line counts from git), commands run and whether they passed, git operations, current branch and commit state. Use this to write an accurate final report instead of relying on memory — and to see what is still uncommitted.