Skip to main content

Why am I asked to confirm it's me when signing in with Git Credential Manager, tea or the CLI?

When an app such as Git Credential Manager opens your browser to sign you in to frem.sh, frem.sh may first show a Confirm it’s you page. Confirm with your passkey or security key, a code from your authenticator app, or by signing in again at your organisation’s identity provider, and the browser goes straight back and finishes the sign-in. There is no second click to allow the app.

You’re asked about once a month on each device, when an app signs in afresh. An app that renews its sign-in in the background is never asked.

What happens

  1. An app on your computer opens your browser at frem.sh to sign you in, for example on your first git push with Git Credential Manager, or when you run fremforge auth login.
  2. If you have not confirmed it’s you in the last 5 minutes, frem.sh shows Confirm it’s you. The page names the app, says where it runs (for an app that does not run on your own computer, “It runs on” and its host), says “Only continue if you started this sign-in.” and links to this page (“Why am I asked?”).
  3. You confirm (see How to confirm).
  4. The browser returns to the app, and the sign-in finishes. You don’t click Authorize a second time.

A confirmation counts for at most 5 minutes and is used up by that one sign-in. If a second app signs in afresh a minute later, you confirm again.

Is this app the one I started?

frem.sh names an app plainly only when it is one it trusts by its client id: Git Credential Manager, git-credential-oauth and tea (built into Forgejo), and the fremforge CLI and the fremforge MCP connector. Any other app is shown with its name in quotes and its owner, for example:

“Example App”, registered by example-owner, wants to sign in to your account. Confirm it’s you to continue.

If the name is in quotes with “registered by”, it is a third-party app. Check that you started this sign-in yourself, from that app. If you didn’t, don’t continue: close the page. Someone may be trying to get a token for your account through an app they registered. Tell your organisation’s administrator or security@frem.sh.

Why frem.sh asks

These apps sign in without a client secret. A program installed on millions of laptops cannot keep a secret, so the OAuth standard calls it a public client. That has one consequence: frem.sh cannot tell the real Git Credential Manager from any other program on a computer that claims to be it.

So if someone had stolen your browser session (a session cookie, for example through malware or a shared computer), they could run a small program of their own, pose as Git Credential Manager or the fremforge CLI, and get a token for your account, without ever knowing your password or second factor.

Confirming it’s you closes that gap. A stolen session alone no longer gets a token: the person has to be present with their passkey, security key, authenticator app, password or identity provider. This is the same idea as GitHub’s “sudo mode”, which asks you to authenticate again before sensitive actions.

Which apps

Every app that signs in to frem.sh without a client secret, including:

  • Git Credential Manager (GCM), as set up in Secure sign-in
  • git-credential-oauth
  • tea, the Forgejo and Gitea command-line client
  • the fremforge CLI: fremforge auth login, both the browser (loopback) sign-in and the device sign-in. See CLI authentication.
  • AI-assistant connectors that sign in to frem.sh as you, see MCP
  • any third-party OAuth app registered as a public client

Apps with a client secret are unchanged. An OAuth app that runs on a server and authenticates with a client secret (a confidential client) signs you in as before, with the usual consent screen.

How often

About once a month on each device. You confirm when an app signs in afresh, not every time you use git:

  • An app that renews its sign-in in the background is never asked. Git Credential Manager’s access token lasts 24 hours and its refresh token 30 days. Within those 30 days, GCM refreshes the token silently on your next push or fetch.
  • The fremforge CLI’s 1-hour tokens refresh silently in the same way.
  • Using a sign-in an app already has never asks. Pushes, fetches, and CLI and connector calls with an existing sign-in go through as before.

You’re asked when an app opens the browser to sign in afresh, which happens:

  • on a new device’s first sign-in, for example a new laptop or a new WSL install
  • after you sign out, or after you remove the app’s access under Authorized OAuth2 applications at frem.sh/user/settings/applications
  • after 30 days without use, when the refresh token has expired

How to confirm

You haveYou confirm with
A passkey or security keyUse your passkey or security key. Synced passkeys (for example in iCloud Keychain, Google Password Manager or a password manager) work too.
An authenticator app (TOTP)A 6-digit code from the app. If you also have a passkey, the code field is below the passkey button.
A password, but no second factor yetYour frem.sh password
Single sign-on through your organisationOne click: Sign in again with your identity provider. If you also have a passkey or authenticator app, this is a link below them.

Single sign-on: one click, a fresh sign-in. frem.sh asks your identity provider for a fresh sign-in, and counts it only if the provider really signed you in just now: someone holding a stolen frem.sh session can’t do that. You don’t need a passkey or a second factor on frem.sh for Git Credential Manager, tea or the CLI. If your organisation requires a second factor at the identity provider, complete it there as usual.

If you cancel at your identity provider, or it didn’t ask you to sign in again (it reused an earlier sign-in), you come back to the Confirm it’s you page, which says so and lets you try again.

With a password but no second factor, the page also says “Set up two-factor authentication, so you can confirm with a code or a security key next time.” With single sign-on only, it says “Set up a passkey or another second factor, so you can confirm here next time.” That is optional: signing in again at your identity provider is enough.

You have 5 attempts in 15 minutes. After that, the page asks you to try again in 15 minutes.

I have no second factor

  • You have a frem.sh password: confirm with your password. Then set up a passkey or two-factor authentication, so that next time you confirm with it. Until you have confirmed once with it, the page keeps offering your password next to the new factor.
  • You sign in only through your organisation’s single sign-on: click Sign in again with your identity provider. That is all.
  • You have none of these: the page tells you to contact your organisation’s administrator or support@frem.sh. We help you set up a second factor.

Troubleshooting

  • The sign-in failed after I confirmed. The confirmation is used up by one sign-in and lasts 5 minutes. If the app timed out in between, run the command again (for example git fetch) and confirm once more.
  • "… didn’t ask you to sign in again, so this couldn’t confirm it’s you." Your identity provider reused an earlier sign-in instead of asking you again. Try once more. If it keeps happening, tell your administrator: the provider is ignoring frem.sh’s request for a fresh sign-in.
  • “Your organisation requires a second factor at … and it didn’t confirm one.” Your organisation’s identity provider is set to require a second factor and didn’t report one. Sign in again and complete the second-factor step there.
  • “You set up this passkey or code in this session, so it can’t confirm an app’s sign-in here.” A factor you have just added can’t confirm an app’s sign-in until you have confirmed it’s you once in another way, so someone with a stolen session can’t add a passkey and use it. There is no waiting: use a factor you had before, your password, or Sign in again with your identity provider, once. After that, the new passkey works as usual, on every device.
  • I’m asked every day. Check that Git Credential Manager can store its token: see the credential.credentialStore setting in step 4 of Secure sign-in. Without a working store, GCM has no refresh token to reuse and signs in afresh each time.
  • A script or CI job stopped working. Unattended jobs should not use an interactive sign-in. Use a personal access token or Forgejo Actions OIDC, which are not affected.