Authenticate GitHits in CI and headless environments

CI environments, SSH sessions, and containers may not be able to open a browser for OAuth. Use an API token for automation. For an interactive SSH session, print the sign-in URL and forward the local callback port from the browser machine.

Option 1: API token (recommended for CI)

An API token lets you authenticate without any browser interaction. The token is read from an environment variable, so you can inject it as a CI secret without modifying your code or config files.

Get your API token

Set the environment variable

Export the token in your shell or add it to your CI configuration as a secret:

export GITHITS_API_TOKEN=ghi-your-token-here

Verify authentication

Confirm that GitHits picks up the token:

npx githits@latest auth status

The output should show you as authenticated and indicate that credentials are sourced from the environment variable.

GitHub Actions example

Add your API token as a repository secret named GITHITS_API_TOKEN, then reference it in your workflow:

jobs:
  build:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4

      - name: Set up Node.js
        uses: actions/setup-node@v4
        with:
          node-version: '20'

      - name: Run GitHits
        env:
          GITHITS_API_TOKEN: ${{ secrets.GITHITS_API_TOKEN }}
        run: |
          npx githits@latest auth status

The same pattern works for GitLab CI (variables:), CircleCI (project environment variables), and any other CI system that supports injecting secrets as environment variables.

Option 2: OAuth over an SSH tunnel

If the CLI runs on a remote host but your browser runs locally, choose a fixed callback port on the remote host:

Remote host

npx githits@latest login --no-browser --port 8765

From the browser machine, forward the same port to the remote loopback listener:

Browser machine

ssh -N -L 8765:127.0.0.1:8765 user@remote-host

Keep the tunnel open, then open the sign-in URL printed by the remote CLI. Replace user@remote-host with your SSH destination.

Option 3: File storage OAuth (scripted environments)

If you need OAuth credentials persisted for a scripted environment that runs repeatedly, you can store them in a file instead of the system keychain:

GITHITS_AUTH_STORAGE=file npx githits@latest login --force

Subsequent runs in that environment read credentials from the file without any browser or keychain interaction.

File storage is not encrypted. The OAuth credentials are written as plain JSON files under your GitHits config directory. Any process that can read files as your OS user can read the tokens. For CI and automation, prefer GITHITS_API_TOKEN — it is easier to rotate and does not leave unencrypted credential files on disk.

You can also set file storage permanently in your config:

# macOS/Linux: ~/.config/githits/config.toml
# Windows: %APPDATA%\githits\config.toml
[auth]
storage = "file"

Choosing the right approach

Scenario	Recommended approach
GitHub Actions, GitLab CI, CircleCI	`GITHITS_API_TOKEN` secret
SSH session with local browser available	`login --no-browser --port <port>` plus an SSH tunnel
Long-running container, no browser	`GITHITS_API_TOKEN`
Local scripted workflow, trusted machine	File storage OAuth

Get Started

Tools

Reference

Guides

Authenticate GitHits in CI and headless environments

Option 1: API token (recommended for CI)

GitHub Actions example

Option 2: OAuth over an SSH tunnel

Option 3: File storage OAuth (scripted environments)

Choosing the right approach

​Option 1: API token (recommended for CI)

​GitHub Actions example

​Option 2: OAuth over an SSH tunnel

​Option 3: File storage OAuth (scripted environments)

​Choosing the right approach

Option 1: API token (recommended for CI)

GitHub Actions example

Option 2: OAuth over an SSH tunnel

Option 3: File storage OAuth (scripted environments)

Choosing the right approach