Git credentials the model never sees

An agent that cannot reach your private repository cannot do much with your code. The usual fix is to paste a personal access token into the chat. That token then lives in the transcript, in the provider’s request logs and in every screenshot of the conversation.

Tarsk takes a different route. You type the token once, into a dialog the model cannot read, and the agent works with plain repository URLs from then on.

The problem with a token in the chat

Chat text is durable. It goes to the model provider, it is written to disk, it shows up in exports, and it survives in the scrollback for as long as the conversation exists. A token in that text is a credential with no expiry date you control and no record of who read it.

Removing it afterwards is manual work. You revoke the token, create a new one, and hope nothing else broke.

What happens when a git command needs credentials

When a command such as a clone, a fetch or a push fails because the remote wants a username and token, Tarsk does not ask the agent to request one in chat.

It opens a secure dialog instead:

• The provider name and host, for example GitHub and github.com.
• A username field.
• A token field labelled for that provider, with a link to the page where you create one.
• Save credentials and Skip.

The token goes straight to the Tarsk server on your machine. The agent gets one fixed sentence back:

Git credentials for github.com were saved. Retry the operation.

If you press Skip, the agent is told you declined, and it stops asking. Free text is refused for this question, so there is no way to type a token into the transcript by accident.

What the agent can still do

Everything you would expect from a working checkout:

• Clone a private repository when you create a project.
• Fetch, pull and push branches.
• Switch branches and read the remote’s history.

Each git command that needs authentication gets a small helper that hands the credential to git, then is deleted when the command finishes. The token is not in the command line, not in an exported environment variable, and not in shell history.

Command output is filtered before the agent reads it. If the secret appears literally, or encoded as base64, hex or URL-encoded text, it becomes [redacted]. The same filter applies to the output file and the logs.

Where the credential lives

Tarsk stores one encrypted record per host and username, in its local database on the machine that runs the server. The encryption key is a file in the same data folder, readable only by your user account.

It is global. Save a credential for github.com once and every project on that machine uses it. Saving again for the same host and username overwrites the record. A different username adds a second record, and the most recent one wins.

Your system keychain is not touched. Every git command Tarsk runs disables the usual credential helper, so git never reads or writes the entry your terminal uses. Nothing changes for your own command-line workflow.

The file is encrypted, and the key sits next to it. That stops casual copying, backup snapshots and another app reading the record. Someone who already has full access to your user account on this machine can read both.

The token is never sent to a model provider, because it never enters a message.

Set it up

1. Create a project from a private repository, or ask the agent to run a git command that needs authentication.
2. Paste your username and token into the dialog when it appears.
3. Press Save credentials. The clone continues, or the command is retried.
4. Open Settings, then Git, to see which HTTPS hosts your projects use and whether a credential is saved for each.

A clone tries a stored credential before it prompts, so a project you connected before does not ask again.

Limits worth knowing

• HTTPS only. The dialog covers HTTPS remotes. SSH remotes use your own keys, and sandboxed commands cannot read your SSH keys, so a push over SSH from a sandboxed command fails.
• No expiry tracking. Tarsk does not check the token’s age or scopes. An expired or under-scoped token shows up as a failed command, and the agent asks again.
• No delete button yet. Saving a new token for the same host and username replaces the old one. There is no separate revoke step in Settings, so revoke on the provider side when you need to.
• No check on the token itself. Settings reports whether a credential exists. It does not test whether the token still works.
• Git 2.31 or newer. Tarsk resets the credential helper on every command, and older versions ignore that setting.

Try it

• Connect a private repository and watch the dialog appear instead of a token request in chat.
• Ask the agent to push a branch, then look at the tool output: the URL is there, the secret is not.
• Save a token with read-only scope and watch the push fail with a clear provider message rather than a silent retry loop.

Download Tarsk or read the documentation.