Read the Right Codespace's Logs with gh codespace logs

gh codespace logs pulls a running Codespace's log output straight to your terminal, and it changes nothing remote while it does it. Allow about ten minutes for a first check: enough time to confirm the binary, pick the right target and read what comes back.

You need the gh command, an authenticated session with access to the Codespace, and either its exact name or enough repository detail to identify it. This command does not rebuild, stop, delete or edit anything, and it does not need sudo.

1. Confirm the installed command

Check the executable and its version first. This is read-only and safe on any shell:

$ command -v gh
/usr/bin/gh
$ gh --version
gh version 2.87.3 (2026-02-23)

Your path and release date can differ; what matters is that this is the GitHub CLI you expect. Confirm the subcommand's own flags too:

$ gh codespace logs --help
Access codespace logs

USAGE
  gh codespace logs [flags]

FLAGS
  -c, --codespace string    Name of the codespace
  -f, --follow              Tail and follow the logs
  -R, --repo string         Filter codespace selection by repository name (user/repo)
      --repo-owner string   Filter codespace selection by repository owner (username or org)

--help earns its keep on a machine with more than one gh on its PATH. Do not borrow a flag from a different GitHub CLI command: this one has a small, specific set.

2. Check authentication without exposing a token

Logs are remote data, so check the account and host before you debug selection:

$ gh auth status
github.com
  ✓ Logged in to github.com account YOUR_ACCOUNT
  - Active account: true
  - Git operations protocol: https
  - Token scopes: ...

The account name and scopes depend on your setup. Never paste a token into an article's commands or a support ticket. If authentication fails, repair it through your normal login process, then rerun gh auth status rather than reaching for repository permissions or deleted credentials.

3. Select one Codespace explicitly

The safest troubleshooting command names the target directly. Swap in the exact Codespace name:

$ gh codespace logs --codespace CODESPACE_NAME

The short option is equivalent:

$ gh codespace logs -c CODESPACE_NAME

The command writes the logs to your terminal and returns once the request completes. A blank screen is not proof that nothing happened: the Codespace may simply have no output for that period. Check the exit status if the result looks wrong:

$ printf 'exit status: %s\n' "$?"
exit status: 0

A zero status means the command completed successfully. It says nothing about whether the log content explains your problem. Read the first and last visible lines, then note the time of any error before you rerun it.

4. Filter an ambiguous selection

Without the exact name, a repository filter narrows Codespace selection. It must be in user/repo form, not a repository's short name:

$ gh codespace logs --repo EXAMPLE_OWNER/EXAMPLE_REPOSITORY

Use --repo-owner when the owner is the useful boundary:

$ gh codespace logs --repo-owner EXAMPLE_ORGANISATION

These flags filter selection; they are not alternate spellings of --codespace. If several Codespaces still match, stop and identify the target rather than grabbing the first plausible entry. If none match, check spelling, owner, repository visibility and the active account: a filter cannot grant access the account does not have.

Once you have identified the name, prefer the explicit --codespace form for a reproducible incident record:

$ gh codespace logs --codespace CODESPACE_NAME > codespace.log
$ test -s codespace.log && echo 'log file is non-empty'
log file is non-empty

The redirection only touches your local working directory. Choose a new filename first, because > truncates an existing file before gh even runs. Check the destination before you overwrite anything else; the remote Codespace is untouched either way.

5. Follow live logs deliberately

Reach for --follow when you need to watch new output while you reproduce a failure:

$ gh codespace logs --codespace CODESPACE_NAME --follow

This is a long-running command. Press Ctrl-C once you have captured enough. Interrupting the local client stops the watch; it does not stop or delete the Codespace. If a terminal looks stuck after an incident, check your shell history for a stray --follow before assuming the network request has failed.

6. Separate selection errors from log errors

Work through failures in this order:

1. Confirm the binary. Run gh --version and gh codespace logs --help.
2. Confirm the account. Run gh auth status to check the account and host.
3. Name the target. Use --codespace with the exact name, not an ambiguous filter.
4. Narrow only if needed. Add --repo or --repo-owner when selection is still unclear.
5. Follow last. Add --follow only after one plain request has confirmed the right target.

This order stops a common distraction: changing several variables at once and losing track of whether the account, the selector or the log stream caused the result. If a request says the Codespace cannot be found, verify its name and visibility from an account that should have access. If the CLI reaches the target but the application still misbehaves, the CLI has done its part; investigate the log lines and the application separately.