git-access

Git through the signed-in Merv account

For code-linked project work, perform this synchronization throughout the active task. Use the existing native MCP connection; do not send the person to Settings/Keys or ask them for a token. List projects and choose the intended explicit projectId, asking only if ambiguous. Read its brief and code status. Git is optional for non-code research tasks. A reader/reviewer can clone or fetch; producer/operator users can push ordinary user branches. Workers use their assigned credentials, never this flow.

The code.git_credential tool takes {projectId, publicKey, mode}. Use read for clone/fetch or write for the user-branch synchronization authorized by normal code-linked work. It returns a relative Git URL, username merv, mode, expiresAt, encryption RSA-OAEP-SHA256, and encryptedToken. The token expires in ten minutes and loses access immediately if the source grant or membership is revoked. A role change invalidates existing derived credentials; request another with the current role. Push admission and reserved refs still apply.

Never print a decrypted token, put it in a URL, command argument, environment variable, plaintext file, tool output or chat. Do not read the native client's private OAuth store. Only public keys and ciphertext cross the model/tool boundary. Use Python 3, OpenSSL and Git's built-in credential-cache, as below. These are ordinary local commands, not an installed Merv helper. Do not substitute Git's plaintext credential store or enable tracing. If these commands are unavailable, report the missing prerequisite; do not create a long-lived key as a workaround.

Keep code-linked work synchronized while you work

For a code-linked project, synchronization is the default part of normal work, not another setup step. Use the selected project's repository and current intended user branch. If the repository/project mapping or branch is ambiguous, resolve that ambiguity before uploading; do not upload an unrelated working directory. In a fresh chat, rediscover the branch and remote instead of inheriting another chat's selection. Each agent keeps its own intended branch; never switch to another agent's branch merely because it is newer. Readers/reviewers fetch and report local-only changes; producer/operator members can push user branches through the same login.