Settings
The Settings section is where you configure everything about a repository that is not day-to-day work on files and branches: what remote it talks to, which access tokens it has available, and which identity the commits you create on this repository should be recorded under.
Layout
The Settings section is a single scrollable column of cards, laid out in a column no wider than a form. Three cards are shown, in this order:
- •Quick Connect: the remote configuration card — set the remote URL, pick how to authenticate, test, add, or remove the remote.
- •Saved Servers: a read-only list of every host you have already stored a token for. Shown only when the list is non-empty.
- •User Config: the name and email that will be used as the author and committer identity on new commits in this repository.
Quick Connect
Quick Connect is how a repository gets wired to a remote in the first place — and how you disconnect or swap it later. The card adapts to the state of the repository in a deliberate way:
- •No remote yet: every field is editable. You fill in a URL, pick how you want to authenticate, provide a token if needed, optionally rename the remote, and click Add Remote.
- •Remote already configured: the Remote URL and Remote Name fields switch to read-only (pre-filled from the existing remote), the Connection Type and Access Token fields are hidden, and only Test Connection and Remove Remote are enabled. To change the remote URL, remove it first and add a new one.
The full set of fields when adding a new remote is:
- •Remote URL: the HTTPS URL of the repository. Placeholder shows the expected shape (https://github.com/team/specs.git).
- •Connection Type: a dropdown with two kinds of options. The default is Use token, which reveals an Access Token input. If you have connected to other hosts before, every one of them is listed below a "Saved Servers" divider in the dropdown — picking one means "authenticate with the token I already have stored for this host", and the Access Token input disappears because it is not needed.
- •Access Token: password-style input, shown only when Connection Type is Use token. This is where you paste a personal access token for the host you are connecting to.
- •Remote Name: the local alias for the remote. Defaults to origin, which is the convention for the primary remote. You can leave it as-is unless you have a specific reason to rename it.
Test Connection, Add Remote, Remove Remote
At the bottom of the Quick Connect card sits a row of three action buttons, each with a tight responsibility:
- •Test Connection: attempts a lightweight authenticated call against the URL you entered, using either the token you pasted (if Connection Type is Use token) or the saved token for the picked host. On success, a green dot appears below the buttons next to the message "Connected — read/write". On failure, a red dot appears next to the error returned by the host — expired token, 404, network issue, anything else — so you can correct the input before saving anything. Nothing is stored until you explicitly press Add Remote.
- •Add Remote: permanently wires this repository to the URL. When you click it the panel does two things in sequence: it registers the remote on the repository under the name you chose, and — if you provided a fresh token — it stores that token into the OS keychain under the URL's host so future operations on that host can pick it up automatically. Only available when there is no remote yet.
- •Remove Remote: disconnects the repository from its current remote. The URL and name fields become empty again and the card returns to its "no remote yet" state, ready for a new one. Removing the remote does not delete the saved token for its host — that stays in the keychain so you do not lose access for other repositories that connect to the same host. Only available once a remote is configured.
Whichever button you press, the status line below them mirrors the result in plain English — "Connected — read/write", "Remote 'origin' added successfully", or an error message — with a colored dot to make success and failure distinguishable at a glance.
Saved Servers
The Saved Servers card lists every host you have already connected to from any repository in the workspace. It is a read-only list — one row per host, each with a small server icon and the host name. The card does not appear at all when the list is empty, so a fresh install will never see it until you have added at least one remote.
The point of the card is to tell you, at a glance, which hosts are ready to be used without prompting for a token. Every host that appears here is an option in the Quick Connect Connection Type dropdown — pick the host there and the Access Token field disappears because the saved token will be used instead.
Removing a host from the saved servers list is not done from this card. It happens automatically when you remove a remote that was the last remote pointing at that host and explicitly drop its token; otherwise the entry stays around so other repositories keep working.
User Config
The User Config card controls the author identity Git attaches to new commits made on this repository. It has two fields and a conditional Save button:
- •Name: the name that will appear on every commit you make in this repository — the same field any Git client sets as user.name.
- •Email: the matching email address — user.email. Hosting providers typically use this value to link commits to a user account.
- •Save: appears only when the current inputs differ from what is already stored. Pressing it writes the values to the repository's configuration so the next commit picks them up. If you edit one of the fields and change it back to the original value, the Save button disappears on its own — there is nothing to save.
This identity is scoped to the current repository, which means each flow group or spec group can have its own author name and email if you want that. Leaving the fields empty is possible — Git will then use whatever global default your system has — but it is usually clearer to set them explicitly per repository so the commits the team sees are always attributed the way you expect.