When outside of a git repo, some commands don't use the host from a self-managed URL passed as argument

Checklist

• I'm using the latest version of the extension (Run glab --version)
  • Extension version: glab 1.79.0 (19f58080)
• Operating system and version: macOS 15.6.1
• Gitlab.com or self-managed instance? self-managed instance
• GitLab version (if self-managed) 18.0.2-ee
• I have performed glab auth status to check for authentication issues
• Run the command in debug mode (like DEBUG=true glab mr list) and attach any useful output

Summary

When the CLI is used outside of a git repo and with a self-managed instance, commands that accept a URL don't always use the host from the URL.

Environment

• OS: Darwin 24.6.0 arm64
• SHELL: /bin/zsh
• TERM: xterm-256color
• GLAB: glab 1.79.0 (19f58080)

Steps to reproduce

One example of an affected command is viewing an issue with comments. Run these commands outside of a git repository:

• This works: glab issue view https://url-of-issue-in-a-self-managed-instance
• This doesn't: glab issue view --comments https://url-of-issue-in-a-self-managed-instance

What is the current bug behavior?

Viewing an issue with comments results in a 401 (Unauthorized) error because the CLI attempts to read the comments from gitlab.com, not the self-managed host.

DEBUG=true glab issue view --comments https://my-self-managed-instance.com/group/project/-/issues/issue-id
[git remote -v]
[git remote -v]
DEPRECATION WARNING: The environment variable DEBUG has been deprecated and will be removed in future releases. Use GLAB_DEBUG instead.
2025/12/06 20:11:19 [The current command request Factory.GitLabClient() without being able to resolve a base repository. The command should probably use Factory.ApiClient() instead]
[git remote -v]

   ERROR

  Get https://gitlab.com/api/v4/projects/group/project/-/issues/issue-id/notes: 401 {message: 401
  Unauthorized}.

What is the expected correct behavior?

The CLI should return the issue with comments. It does if I force it to use the correct host by specifying an ENV var:

GL_HOST=my-self-managed-instance.com glab issue view --comments https://my-self-managed-instance.com/group/project/-/issues/issue-id

Possible fixes

There seems to be this pattern in the commands that accept a URL ( issue/incident/MR):

• The command creates a gitlab client, which is uses the default host
• The command attempts to load the resource by the URL (e.g. read an issue), which parses the URL and creates a new gitlab client that uses the host from the URL
• Any subsequent operations (e.g. reading comments to an issue) are still performed using the original gitlab client and therefore the default host is used.

To fix this, commands could instead:

• parse the passed URL
• use the host from the URL to create a gitlab client
• use that gitlab client for all operations