User Guide
A task-oriented tour of Desktop Material's features. It assumes you already know the basic GitHub Desktop workflow (clone, commit, push, branch, pull request) — that all still works. This guide focuses on what Desktop Material adds on top.
Feature guide
The complete M0–M19 roadmap is published on main. This guide also covers the current maintenance
release: adaptive appearance and profile app identity, favorite/portable tabs, Material entry surfaces, guarded tab management, workflow-run
cancellation, reviewed rebase, repository-account propagation, bounded OAuth scopes, and compact
surface corrections, plus the repository-contextual GitHub API Explorer. Exact build, off-screen UI, publication, and cleanup receipts are recorded in
the repository's HANDOFF.md only as each release is verified.
The Guided Feature Gallery is the canonical 58-function visual index: every
catalogued function or state owns one distinct screenshot rather than borrowing an overview image.
- The shell
- Material first run
- Signing in
- Repository tabs
- Appearance customization
- Settings history
- Non-modal dialogs
- Multi-clone
- Guided Git and GitHub functions
- GitHub API Explorer
- One-click commit & push
- Notification centre
- GitHub Actions panel
- UI scaling
- Automation and merge-all
- History search and graph
- Multiple stashes
- Repository power tools
- Multi-window workflows
- Agent access and CLI
Desktop Material rebuilds the GitHub Desktop shell around Material Design 3. The chrome you work in every day is made of a few pieces:
- A left icon navigation rail with entries for Changes (with a count badge), History, Branches, Settings, and your account avatar at the bottom.
- A floating pill toolbar across the top carrying repository, worktree, branch, and sync controls. When the measured width gets tight, Build & Run moves into the keyboard-accessible More toolbar actions surface first, then Commit & Push follows. Widening the window restores each action automatically before its label can clip.
- Browser-like repository tabs (see Repository tabs) above the workspace.
- Floating, radius-24 workspace cards for Changes, the diff, History, and the empty/welcome states, with tri-state selection checkboxes, tonal status chips, token-based diff colors, and an inverse-surface undo banner.
The whole shell has an animated light/dark theme. Everything below tells you how to drive it.
The welcome page is a Material task surface rather than a separate stock onboarding skin. It keeps the Sign in with GitHub.com, GitHub Enterprise, and Continue without signing in routes in one focused card, preserves keyboard focus and sign-in progress, and explains that repositories stay local to the device. A tonal preview introduces the repository-focused workspace; at compact window sizes the preview steps away so the setup task remains unclipped.
Open Settings → Accounts to manage sign-ins. Desktop Material supports multiple accounts at once and, unlike stock GitHub Desktop, multiple identities on the same host — for example two GitHub.com accounts, or a work and a personal GitHub Enterprise identity side by side.
- In Settings → Accounts, choose Add account.
- Pick GitHub.com or GitHub Enterprise and complete the browser sign-in.
- The new identity appears in the accounts list. You can add another on the same host without signing the first one out.
Each account keeps its own tabs, repositories, and settings. Switching the active account switches the whole workspace to that identity's context.
GitHub browser sign-in requests only the feature scopes used by Desktop Material: repository/user access, workflow-file updates, notifications, and read-only organization membership. It does not request unrelated repository deletion, administrative key, package, codespace, audit, or gist scope families.
Desktop Material signs in to self-hosted GitLab with an endpoint + personal access token (PAT) rather than a browser OAuth flow:
- In Settings → Accounts, choose Add account → GitLab (self-hosted).
- Enter your instance endpoint (for example
https://gitlab.example.com). - Paste a personal access token with the scopes you need (typically
api,read_repository,write_repository). - Save. The GitLab identity now behaves like any other account — its repos are browsable and cloneable, and it can own its own tabs.
Bitbucket and hosted GitLab integrations follow the same pattern. Tokens are stored with your platform credential store and are never exposed through the agent API.
When a GitHub account belongs to organizations, the clone view loads the account's organization list and adds filter chips. Select an organization to browse its complete repository list; if one organization fails to load, the view reports that error without hiding the repositories already available. The publish dialog uses the same organization list, so choose the owner before creating the remote repository.
Repository-bound provider features use Repository settings → Repository account as their one source of truth. If Provider Triage opens while the repository is unassigned, Desktop Material automatically uses the account only when exactly one signed-in identity matches the provider and endpoint. With multiple matches, choose a labelled account and select Use this account; this prevents cross-account API calls. With no match, use Sign in or Manage accounts.
If the saved account has been signed out, lost permission, or needs organization SSO, the tool asks you to re-authenticate or authorize SSO instead of claiming the repository is unassigned. Changing the account in Repository Settings propagates to Provider Triage immediately; an existing valid explicit binding is never silently replaced.
The workspace is browser-like and tabbed. Each tab is bound to a repository and an account, so a tab always opens in the identity that owns it.
- Click + on the tab strip to open a new tab, then pick a repository, or
- Middle-click / use the context menu on a repository in the list to open it in a new tab, or
- Drag one or more local repository folders onto the app. An existing repository switches instantly; a new valid repository is added and opened as a tab.
Tabs persist per account — reopening the app restores that account's tabs.
Double-click a tab's title (or use its context menu → Rename) to edit the label inline. The rename is local to the tab and does not touch the repository name on disk or on the remote.
Open a tab's context menu → Text style to open the styling popover. Per tab you can set:
- Weight — bold on/off
- Italic and underline
- Size
- Text color — choose from the palette or use a custom color
- Background color — choose independently from the same palette or use a custom color
- Font family
- Alignment
The picker keeps a short recent-colors row for reuse. Styling is per tab, so you can give a production repository a strong background while leaving a scratch repository muted and italic to tell them apart at a glance.
Tab layout and styling are part of your per-account settings, so every change auto-commits to that account's local settings repo. Open Edit → Settings History… or press
Ctrl+Alt+Zif you ever need to inspect, undo, redo, or restore an earlier state.
The tab-strip menu keeps both directions explicit:
- Close Tabs Containing… uses the existing regular-expression workflow to close matching tabs.
- Close all tabs except those containing… keeps tabs whose visible label, repository alias/name, or local path contains a case-insensitive literal query. Review the live kept, closed, and pinned counts plus the bounded preview before confirming. Empty input and a query with zero matches cannot confirm, so this action cannot accidentally become close-all.
Pinned tabs are protected in both bulk-close directions. Unpin one explicitly before including it in a bulk close.
Use the star control or context menu to mark a tab as a Favorite, and use Pin tab when it must remain in the leading group. Open Arrange tabs to:
- drag a tab within its current pin group;
- use the named Move left, Move right, Move first, and Move last keyboard actions;
- apply one-shot A to Z, Z to A, Newest opened, Oldest opened, Needs attention first, Clean first, Favorites first, or Favorites last ordering.
Each sort is a one-time edit: later repository-status changes do not reshuffle the strip. The saved order remains manually editable and restores with the account/window tab state. Pin or unpin a tab explicitly before moving it across the group boundary.
Choose File → Export current tabs… to save a portable JSON description of the open tab order, active tab, aliases, pins, favorites, and per-tab appearance. The file includes local repository paths but never account tokens or credentials. Choose File → Import current tabs… to validate a file, preview it, then replace the current tabs or merge with them; missing folders are skipped without destructively clearing a usable current session.
Open Settings → Appearance. The callout at the top identifies these controls as app defaults for the active profile. All 12 are saved through the profile's local Git-backed settings history:
- Accent color — Blue, Violet, Teal, Green, Amber, or Rose.
- Surface color — Tonal or Neutral.
- Surface depth — Standard, Subtle, or Flat.
- Interface font — Material (Roboto) or the system font.
- Code and diff font — platform default, Consolas, or SF Mono.
- Animation — follow the system setting or reduce motion.
- Toolbar labels — Automatic, Prefer labels, or Icons only.
- Toolbar density — Comfortable or Compact.
- Repository list density — Comfortable or Compact.
- Tab density — Comfortable or Compact.
- Tab width — Compact, Standard, or Wide.
- Tab close buttons — On hover, Always, or Active tab only.
Changing profile switches these defaults with the rest of that account's settings. Open
Edit → Settings History… (Ctrl+Alt+Z) to inspect, undo, redo, or restore an appearance change
without rewriting the profile history.
At the top of Settings → Appearance, use the live App identity preview to customize the in-app name and logo. Logo controls cover visibility, built-in/custom artwork, shape, size, inset, rotation, gap, border, shadow, and colors. Name controls cover font, width, weight, case, size, spacing, opacity, bold/italic/underline/strikethrough/small-caps, highlight, and text effects. Use Clear name formatting for typography only or Reset identity for the entire identity.
The result follows the active profile, participates in Settings History, and restores after an app restart. It does not rename the signed executable or operating-system icon. Right-click an appropriate shell element to open its customization route and see the owning profile Git-history path; repository surfaces instead identify that repository and can open its commit history.
Open Repository settings → Appearance when one project needs a different workspace. The six optional overrides are accent color, surface color, toolbar labels, toolbar density, tab density, and tab width. Every field starts at Use app default and independently inherits the active-profile value until changed.
These six values are stored under desktop-material.appearance in the repository's local
.git/config. They are not committed and are not shared with collaborators. Interface/code fonts,
surface depth, motion, repository-list density, and tab close-button behavior intentionally remain
profile defaults; individual tab text/background styling remains in the profile's tab history.
Desktop Material records every per-account settings and repository-tab change as a commit in that
account's local settings repo. Open Edit → Settings History… or press Ctrl+Alt+Z to open the
non-modal right-side sheet; the workspace remains usable while it is open.
- Select a timeline entry to lazily load its changed files and diff.
- Choose Undo last to reverse the latest logical change, or Redo to replay an undone change.
- Use an entry's restore action to confirm and restore the complete settings state at that point.
- Choose Load more when the timeline contains more entries than the first page.
- Undo, redo, and restore all append audit commits, so the history itself is never rewritten.
Desktop Material's dialogs are non-modal floating surfaces — the main window stays fully interactive while a dialog is open.
- Drag a dialog by its header to reposition it, and keep working in the app behind it.
- Click or focus a dialog to bring it to front; multiple open dialogs cascade so you can see them all.
- OS-native pickers (file open/save) stay native.
Preferences is the reference surface: an MD3 940×660 dialog with a left navigation rail, an Active chip on the current section, and a pill footer. The repository and branch pickers open as MD3 side sheets rather than blocking modals.
The multi-clone window clones many repositories in one pass.
- Open Clone → Multiple repositories (or the multi-clone entry in the repositories menu).
- The list shows every repository available to the active account. Use the search bar — with filter chips, regex mode, and the regex builder (see the Regex Guide) — to narrow it down.
- Use org filter chips to limit the list to a specific organization.
- Tick the checkboxes for the repositories you want.
- Choose the clone mode:
- Parallel — clone all selected repos at once (fast; heavier on network/disk).
- One-by-one — clone sequentially (gentler; easier to watch progress and spot failures).
- Start the clone. Progress is shown per repository.
On a compact or zoomed viewport, the builder stacks its category and building-block areas before cards clip. Its body scrolls vertically while the live tester and footer actions remain reachable; the dialog does not require page-level horizontal scrolling.
- Export writes the selected repositories to a list file containing URLs only — no tokens, no credentials.
- Import loads such a list back into the checkbox selection, so you can re-clone the same set on another machine or share a curated set with a teammate.
Desktop Material turns useful Git, GitHub CLI, and GitHub API capabilities into named, task-specific workflows. You choose an action, complete a focused form, review any destructive or worktree-changing step, and receive the result in the app. Expert API integration is kept in the separate repository-contextual Explorer below; it does not turn the guided Git workflows into a raw command console.
Open API in the repository rail to work against the GitHub host and account explicitly bound to the selected repository. The Explorer never falls back to another identity on the same host.
- Search the complete current catalog of 1,206 REST operations by method, path, summary, or operation ID, narrow it by category, or choose the New operations scope to see exactly the 10 operations added since the prior pinned 2026-03-10 catalog.
- Select a catalog result to populate its method and repository-aware path, or switch between the REST and GraphQL request builders for an explicit request.
- Read requests can run directly. REST write methods and GraphQL mutations first show a Review GitHub API mutation step with the exact account and request preview; they run only after Run reviewed request is confirmed.
- The response view exposes status and allowlisted diagnostic headers, bounds and truncates the displayed body, and recursively redacts credential-shaped values before rendering them.
Open File → Clone repository… → URL when you need only recent history:
- Enter the repository URL and local path.
- Enable Shallow clone.
- Set Commit depth to the number of commits to fetch.
- Review the summary, then choose Clone.
The form explains that it fetches the current branch and recursive submodules. If you need older history later, use the named deepen-history action in Repository tools.
Open the Tools rail, find History depth, and choose Check history status. When Git reports a shallow boundary, choose Review bounded deepen to fetch a specific number of older commits or Review full history to remove the boundary deliberately. The review names the selected remote, scope, and consequence before the bundled Git runtime starts. Progress is cancellable, and the app rechecks the marker when the fetch completes.
The production fixture began with 3 visible commits and finished with all 15; the clean screenshot below shows the final state. The raw verification receipt is retained in the P0 run manifest.
Open Repository → Manage sparse checkout… to keep selected directories in a large worktree. The side panel reports whether sparse checkout is enabled, explains cone mode, and accepts one repository-relative directory per line. It normalizes slashes and rejects absolute paths, traversal, option-like input, control characters, blanks, and duplicates before the review step.
Choose Review enable only after the valid-directory count matches your intent. The verified disabled state below leaves all working-tree paths eligible to appear locally.
These forms wrap labels and stack actions as space narrows. Page-level sideways scrolling is not part of the workflow; only inherently spatial content such as code, diffs, and logs may scroll horizontally when preserving columns is necessary.
Open Branch → Rebase current branch…, then search for and select the target/base branch. The review shows the current→target relationship, ahead/behind context, and a bounded preview of commits that would be replayed.
Before Git starts, Desktop Material refreshes repository state and blocks unresolved conflicts, dirty changes, and another ongoing operation. It also revalidates the exact current and target refs, so a stale branch picker cannot launch a different rebase. You can cancel while that preflight is running. If Git reports conflicts after start, resolve them through the existing continue/abort flow. Protected branches receive explicit guidance, and the app never force-pushes automatically; review any later force-with-lease decision separately.
Open Branch → Create pull request while the head branch is checked out:
- Confirm the exact target repository and signed-in account.
- Choose the base branch; the current local branch is the fixed head.
- Enter a title and optional Markdown description, and choose whether to create a draft.
- Select Review pull request and verify repository, account, base/head, title, body, and draft state.
- Select Create pull request. The success receipt offers Done and Open on GitHub.
The app rejects ambiguous remote syntax and routes account problems to repository settings. The
workflow does not expose gh pr create, editable arguments, or a raw REST request.
Open Repository → Inspect branch rules…. The non-modal sheet combines classic protection and rulesets for the checked-out branch into plain-language sections for reviews, checks, deployments, merge queue, verified signatures, linear history, update/delete/force policy, bypass context, and source rulesets. Use Refresh to load the same exact branch again.
If no matching account is signed in, Open account settings is shown. If more than one account
matches a legacy repository, Open repository settings opens the real repository-account picker;
saving one records its stable endpoint#id identity. Unknown or partial policy evidence is stated
instead of guessed.
For quick, low-ceremony commits, use one-click commit & push:
- Stage the changes you want (or commit everything shown in Changes).
- Press the one-click commit & push action.
- Copilot writes the commit message from your staged diff.
- Desktop Material commits and pushes in a single step.
This is a convenience path built on the normal commit machinery — you can always fall back to writing the message yourself in the Changes view. For scheduled, unattended commits and pushes, see Automation.
The bell in the app chrome opens the notification centre side panel. Its two named views keep local app events separate from GitHub inbox items:
- Local is backed by its own git repo. An unread badge shows how many notifications you have not seen. Search titles and messages, filter by notification type, select every visible result, and apply Mark read, Mark unread, or Delete selected as one history-backed change. Clear all opens an inline confirmation and the notification history can restore the removed entries later.
- GitHub uses an explicit account selector with All, Unread, and Participating only controls. Search loaded titles, repositories, types, and reasons; select all visible matches; then mark them read or done in bulk. Changing account, source, filter, or search safely resets the scoped selection. When no account is signed in, the complete No signed-in accounts state remains visible and tells you to sign in before refreshing the inbox.
The account, filters, and empty state are part of the guided inbox workflow rather than a gh
command or GitHub API search screen.
Acknowledgement-only failures appear as dismissible red notices in the bottom-right corner by default, without blocking the task underneath. A notice can expose bounded diagnostic details when they differ from the user-facing message. In Settings → Notifications, choose either Bottom-right notice or Blocking dialog for these acknowledgement-only errors. Failures that need a retry, authentication choice, external remediation, or another real decision remain dialogs regardless of that preference.
The Actions panel brings CI into the app:
- Workflow runs for the current repository, newest first. When more are available, choose Load more runs; already loaded pages remain visible across background polling and Refresh.
- Filters by workflow, status, branch, and event.
- Re-run a whole run or re-run only the failed jobs.
- For a run that is queued, running, waiting, or pending, choose Cancel run. The Material review names the workflow and run number plus its branch/ref, actor, and commit when GitHub supplied them. Desktop Material revalidates the selected repository/account/run and live cancellable state immediately before one normal cancel request, disables duplicate submission, and refreshes until GitHub reports cancelled or another terminal state. Authentication/SSO and stale/conflict errors keep specific recovery guidance visible; force-cancel is not the primary action.
- Drill into a run, choose the current or a historical attempt, and use Load more jobs to append the next bounded 50-job page. A failed later page keeps the jobs already loaded and offers the same named retry. Every loaded job retains its exact View logs and Re-run job actions.
- Open the in-app log viewer to read output without leaving Desktop Material. Search the loaded log to isolate a command, warning, or error; only the spatial log body may pan horizontally.
- Inspect pending deployment environments and prior review history. Select only environments for which the signed-in account is eligible, enter a required bounded comment, review the exact approve/reject intent, and confirm. Locked environments keep their explanation visible.
- When GitHub marks a first-time fork run as eligible, use the separate Approve fork run confirmation. It is never inferred from a deployment decision.
- Trigger manual workflows with the
workflow_dispatchdialog — pick the workflow, ref, and inputs, and dispatch. - Select a run artifact to review its name, size, creation/expiry, workflow source, and GitHub digest. Choose Load more artifacts to append the next bounded page. A failed later page keeps the cards you already loaded and lets you retry that same page. Download archive opens the native save picker; after transfer, Desktop computes SHA-256 locally, reports whether it matches, and offers Show in folder.
- Check attestations reports whether an attestation record is present. Presence is not presented as cryptographic verification: signer, signature, timestamp, source identity, and policy still need a future verification function.
The historical M0–M19 production gates exercised 50→51 filtered runs, 30→31 artifacts, and current/historical 50→51
job pages, including a deliberate later-page 503→200 retry. Exact job log/re-run, deployment review,
and fork approval mutations ran only against the isolated provider. At regular and short windows
plus a requested 200% base with auto-fit, document and body widths matched and the measured Actions
surfaces had no clipping, overlap, outside controls, oversized text, or page-level sideways
scrolling. Modal focus and scrim ownership were also contained. These are named app controls; there
is no gh command, API-path, or GraphQL editor.
Job-log downloads follow GitHub's signed redirect automatically. Desktop Material's main-process request filter tracks the original request and removes authentication, authorization, and cookie headers before any cross-origin hop. Download errors also omit signed URLs and query strings. The live Windows x64 proof below shows the resulting searchable, collapsible log viewer.
Desktop Material scales its whole interface independently of the OS:
- Open the scaling slider and set anywhere from 50% to 200%.
- Or choose auto-fit to window, which picks a scale that fits the current window size.
- Auto-fit treats your slider value as the requested maximum. If the window is too small, it caps the effective scale instead of multiplying the requested scale again. At the supported minimum window size, 200% auto-fits below that maximum so the title bar, navigation rail, Appearance cards, value, and footer remain visible without horizontal clipping. The latest P0 gate measured 94%; the older screenshot below records a 96% viewport.
Combined with the animated light/dark theme, this lets you tune the workspace for a laptop panel, a 4K monitor, or a shared screen without touching system display settings.
The responsive toolbar gate measures the space its controls actually need. As the window narrows, Build & Run enters More toolbar actions first and Commit & Push enters next; the repository, worktree, branch, and sync controls remain available in the app bar. Opening More keeps the moved actions keyboard reachable. After the surface closes and the window widens, Commit & Push and then Build & Run return to their original positions, with no page-level horizontal overflow.
The Pages gallery also has a dedicated accessibility/clipping check at 960×660 and 390×844. It passes with zero axe violations, matching document/body widths, and no horizontally outside elements.
Open Settings → Automation to configure the two background schedules:
- Turn on Automatically commit and push and/or Automatically pull.
- Pick an interval for each enabled operation.
- Under Account overrides, let an identity inherit the global value or override its enabled state and interval.
- For one repository, open Repository settings → Automation and inherit or override the two schedules again.
Automation targets the selected repository only. Before each run it checks repository state, upstream availability, conflicts, in-progress Git operations, and draft commit text. An unsafe repository is skipped rather than overwritten. See Automation for the complete guard table.
The Branches and Worktrees views also expose Merge all branches and Merge all worktrees. Confirm the target, follow each row's progress, and review any skipped or failed target. When Copilot conflict assistance is available, it participates inside the same guarded workflow.
Open History and use the search field to match a commit's title, message, tag, or hash. The results retain the normal commit detail view. Toggle Show commit graph to add ancestry lanes and merge edges beside the unfiltered list; turn the graph off when a compact list is more useful.
Create a stash from the Changes workflow whenever work must be set aside. Desktop Material keeps all stash entries instead of treating only the newest one as available:
- Expand Stashes in Changes and select an entry by its label.
- Inspect that stash's file list and individual diffs before acting.
- Choose apply or pop for the exact entry, or review rename, create-branch, and delete actions.
- If Git completes only part of an operation, keep the reported state visible and inspect the repository before retrying instead of assuming an all-or-nothing result.
Switching branches can still offer to stash local work, and the resulting entry appears in the same list.
- Open the repositories side sheet and choose Pull all to fetch/pull every eligible repository; review the per-repository result instead of assuming the batch succeeded as one unit. If the normal pull ends in an HTTPS authentication or repository-not-found ambiguity, Desktop Material can try the remaining token-bearing signed-in accounts whose HTML origin exactly matches that remote. A repository-bound identity is preferred within the otherwise stable account order.
- Pin important repositories from their context menu, hide the automatically maintained Recent group if desired, and use grouping to keep large repository lists manageable.
- Use branch presets/default-branch controls when creating or switching branches; pin, hide, solo, and restore branch visibility from branch context and filtered-state controls.
- Set a repository-specific external editor when the global editor is not appropriate.
- Manage every named remote in Repository settings → Remote, and administer add/move/rename/ lock/repair/remove/prune worktree operations from the Worktrees view. Remote names and URLs wrap only when genuinely long; before a field/control column becomes unreadable, each row changes to a single-column layout with fetch/push controls and actions in keyboard order.
- Open Repository settings → Submodules and choose Add submodule… to browse GitHub.com, Enterprise, GitLab, or Bitbucket with the appropriate exact account, or enter an HTTPS, SSH, or local Git URL. Review the repository-relative checkout path and optional branch; Desktop rechecks duplicate/occupied destinations immediately before Git, reports bounded clone progress, and lets you cancel the running operation before refreshing the managed list.
- Use the
.gitignoremanager and one-click Build & Run for project-aware cleanup and execution. Build & Run discovers common nested projects across Node, Deno, Rust, Go, .NET, Python, JVM, PHP, Ruby, Swift, Dart/Flutter, Elixir, Scala, Haskell, Zig, Make, and CMake; choose a profile by its displayed project folder when several projects share a language or toolchain.
At compact heights, the Repository Tools workspace itself scrolls vertically so the Diagnostics section, results, and later actions remain reachable without a horizontal page scrollbar.
SSH and non-authentication failures never start account fallback. The selected stable account key stays in the app's internal trampoline map; its selector field is removed from the Git options before spawn and never enters child, hook, Git LFS, or log environments. A missing same-origin selection fails closed, while credential requests from cross-origin submodules retain normal account resolution. Successful fallback uses the neutral result Pull completed using another signed-in account.
Right-click a repository and choose Open in new window. Worktree context menus offer Open Worktree in New Window as well. Each window maintains its own selected repository and repository tabs, and native/menu/CLI actions route to the correct window. Closing and reopening the app restores the persisted window tab state.
Open Settings → Agent access and turn on Enable local agent server. The panel shows the random loopback address, MCP URL, and bearer token; reveal/copy the token only for a trusted local client, and use Regenerate token to disconnect existing clients immediately.
- HTTP-capable MCP clients connect to the displayed
/mcpURL with anAuthorization: Bearer …header. - Stdio-only clients run
node script/agent/mcp-stdio-proxy.js. - Scripts can start with
node script/agent/desktop-agent.js infoand use the fallback command-line client for the same bounded command contract.
The contract covers account/repository/tab discovery, repository status, single/batch clone, commit, fetch/pull/push, branch creation/merge, tab selection, automation status/runs, and Actions workflow dispatch. It never returns provider credentials. See Agent API for command and security details.
Next: Automation · Regex Guide · Developer Guide