Problem
When multiple external auth providers are configured for the same Git hostname (e.g., two GitHub providers with different token scopes), there is no way for a template to control which provider's token is used for GIT_ASKPASS-mediated git operations (clone, push, pull, coder dotfiles, etc.).
The template author can already scope token usage at build time via coder_external_auth data sources (which reference providers by ID). But at runtime, the agent's GIT_ASKPASS handler resolves tokens purely by matching the git hostname against provider regexes, that is, it has no knowledge of which providers the template declared.
This means all workspaces on a deployment share the same token selection logic regardless of their template, making it impossible to enforce per-template token scoping for git operations.
Use Case
An organization wants to use different GitHub App tokens with different permission scopes per template type:
Template T1 (general development): uses auth_provider_1 with broad repo access
Template T2 (CI/CD): uses auth_provider_2 with limited, read-only access
Template T3 (dotfiles setup): uses auth_provider_3 scoped to personal dotfiles repos
At build time, each template references the correct provider via coder_external_auth. But once the workspace is running, any git operation that goes through GIT_ASKPASS ignores this configuration and picks a provider based on hostname regex matching, potentially returning a token with the wrong scope or no access at all.
Why Existing Workarounds Are Insufficient
Path-scoped regexes (CODER_EXTERNAL_AUTH_X_REGEX=github\.com/orgname) can differentiate by org/path, but require git config --global credential.useHttpPath true in every workspace, and don't help when the same repos need different tokens depending on the template. Also, For different repos, We would need to configure separate external auth providers (for regex matching to correctly differentiate) which is not at all scalable.
Injecting GITHUB_TOKEN via coder_agent.env bypasses GIT_ASKPASS but requires template authors to manage token injection manually and doesn't integrate with Coder's token refresh lifecycle.
Problem
When multiple external auth providers are configured for the same Git hostname (e.g., two GitHub providers with different token scopes), there is no way for a template to control which provider's token is used for GIT_ASKPASS-mediated git operations (clone, push, pull, coder dotfiles, etc.).
The template author can already scope token usage at build time via
coder_external_authdata sources (which reference providers by ID). But at runtime, the agent'sGIT_ASKPASShandler resolves tokens purely by matching the git hostname against provider regexes, that is, it has no knowledge of which providers the template declared.This means all workspaces on a deployment share the same token selection logic regardless of their template, making it impossible to enforce per-template token scoping for git operations.
Use Case
An organization wants to use different GitHub App tokens with different permission scopes per template type:
Template T1 (general development): uses auth_provider_1 with broad repo access
Template T2 (CI/CD): uses auth_provider_2 with limited, read-only access
Template T3 (dotfiles setup): uses auth_provider_3 scoped to personal dotfiles repos
At build time, each template references the correct provider via
coder_external_auth. But once the workspace is running, any git operation that goes throughGIT_ASKPASSignores this configuration and picks a provider based on hostname regex matching, potentially returning a token with the wrong scope or no access at all.Why Existing Workarounds Are Insufficient
Path-scoped regexes (
CODER_EXTERNAL_AUTH_X_REGEX=github\.com/orgname) can differentiate by org/path, but require git config --global credential.useHttpPath true in every workspace, and don't help when the same repos need different tokens depending on the template. Also, For different repos, We would need to configure separate external auth providers (for regex matching to correctly differentiate) which is not at all scalable.Injecting
GITHUB_TOKENviacoder_agent.envbypassesGIT_ASKPASSbut requires template authors to manage token injection manually and doesn't integrate with Coder's token refresh lifecycle.