Local sessions blocked when origin cannot be verified (SSH remotes on GHE)

[MarvinTeichmann]

Project is unusable when git fetch fails: origin verification hard-blocks all local session creation (SSH remotes on GHE)

Summary

Adding a local repository whose origin the app cannot verify makes the project completely unusable — every attempt to create a session fails with:

project <id> origin could not be verified; fix the repository's Git config or remove and re-add the project

There is no way to work locally, and no setting to opt out of the check.

Two distinct problems, in priority order:

1. Local-only work should not depend on remote verification (main issue) — all local functionality is blocked by a remote check that has nothing to do with editing local files.
2. The origin check rejects remotes that plain git handles fine (secondary) — the app fails to verify SSH remotes on a GitHub Enterprise host, even though git fetch/ls-remote/push all succeed against the same remote from the same machine.

Environment

GitHub Copilot app	1.1.12
Bundled CLI	1.0.80
macOS	26.5.2 (arm64)
git	2.53.0
Remote host	GitHub Enterprise (company.ghe.com)

---

Issue 1 (main): local work should not require a verifiable remote

I want to use the app to work on a local checkout. It should not need the remote at all — but a failed remote check disables the whole project.

The check is a hard block, not a warning. Both workspace types fail:

• create_worktree_workspace → fails
• create_branch_workspace → fails (the gate is at project level, so there is no fallback)

This is inconsistent with how the app treats the same failure elsewhere. Other operations already degrade gracefully:

WARN Failed to fetch before listing branches; using cached refs
WARN Failed to check whether remote is unborn; skipping seed
INFO Created project from path name=<repo>          <- project creation itself succeeded

So project creation tolerates an unreachable remote, but session creation does not. If creating the project works offline, working in it should too.

Requested behaviour

Any of the following would resolve this:

• Downgrade origin verification to a warning for local/worktree/branch sessions, and only hard-fail for operations that genuinely need the remote (push, PR creation, cloud sessions).
• Add an opt-out setting, e.g. automation.verify_origin: false in .github/github-app.yml, or a per-project "work offline / local only" toggle.
• At minimum, offer a "continue anyway" action in the error dialog.

Note that today .github/github-app.yml only supports automation.auto_issue_session and automation.remote_control — there is no way to disable this check.

Why "remove and re-add the project" does not help

The error tells the user to remove and re-add the project. That is misleading: re-adding re-runs the same verification and fails identically. The suggestion sends users into a loop, and (as below) the underlying Git config was not actually invalid.

---

Issue 2 (secondary): origin verification rejects remotes that git accepts

The app could not verify this remote:

user@company.ghe.com:org/<repo>.git

Plain git has no problem with it. Verified from the same machine, including under a stripped-down environment (env -i) to rule out shell/env differences:

$ git ls-remote --heads origin
1111111...  refs/heads/main
2222222...  refs/heads/master

Fetch, pull and push all work normally in the terminal.

A/B test

Same repo, same SSH key, same agent — only remote.origin.url changed between runs:

remote.origin.url	Session creation
user@company.ghe.com:org/<repo>.git (SCP-style)	❌ origin could not be verified
ssh://user@company.ghe.com/org/<repo>.git	❌ origin could not be verified
https://company.ghe.com/org/<repo>.git	✅ session created

Reproduced several times in both directions.

The failure is local, not a network/auth failure

When session creation fails, no git subprocess error is logged — only:

ERROR github_app::handlers::workspace: failed to create worktree workspace
  error=project <id> origin could not be verified; ...

No ls-remote or fetch invocation appears at that point, so the check fails before any connection is attempted. This is URL parsing/matching, not connectivity.

Parsing is inconsistent within the app

The app did parse the same SSH URL correctly at project creation time — it stored the right values in data.db:

github_owner = org
github_repo  = <repo>

So the creation path understands the URL, but the verification path does not. The binary also contains two separate messages, suggesting the parse simply returns nothing here:

• origin points to <X>, not the saved repository (parsed, mismatched)
• origin could not be verified; ... (could not determine owner/repo at all)

Only the second is ever hit.

Scope

git@github.com:owner/repo.git remotes work fine, so this appears specific to SSH remotes on Enterprise hosts (or possibly to the SSH login name, since this GHE instance uses a custom one rather than the conventional git@). I did not isolate which. Note that user@ in the examples above is a redacted placeholder for that custom login name, not the literal string.

---

Reproduction

1. Clone a repo from a GHE host over SSH so origin is user@ghe.host:owner/repo.git.
2. Confirm git fetch origin and git push work in the terminal.
3. Add the local folder as a project in the Copilot app.
4. Try to create a session (worktree or branch).
5. Session creation fails with origin could not be verified; the project cannot be used at all.

Workaround

Point remote.origin.url at the HTTPS form so the app's parser accepts it, and use insteadOf so all traffic still goes over SSH:

git remote set-url origin https://ghe.host/owner/repo.git
git config url."ssh://user@ghe.host/".insteadOf "https://ghe.host/"

git config --get remote.origin.url (what the app reads) returns HTTPS, while git rewrites every real operation to SSH. Confirmed with GIT_TRACE=1:

run_command: ssh -o SendEnv=GIT_PROTOCOL user@ghe.host 'git-upload-pack ...'

This works, but it requires per-repo Git config edits purely to satisfy the app, and it makes remote.origin.url misrepresent the real transport.

Related minor issue

On a GHE-only account, this fires on every launch:

ERROR github_app::handlers::workflows: failed to resolve cloud workflow access
  operation="list_cloud_workflow_metadata" error=a github.com account is required for this operation

Cloud workflows are github.com-only and unavailable to these users, so the app should skip the call rather than log an error each start.