Sessionboxer

Run Claude Code in GitHub Codespaces: how it logs in, why the codespace stops under it, and what the agent can reach

Claude Code runs well in a codespace until the idle timer or the 12-hour limit stops it. How to set it up, keep the login, and what the agent can reach.

Sessionboxer's New session form with Claude Code as the provider, a git repository to clone into /workspace, the model and effort pickers, the agent's instructions and the MCP servers

You want Claude Code off your laptop. A codespace looks like the obvious place: one click on the repository page, a Linux machine in GitHub's cloud, VS Code in the browser, and nothing of yours on its disk. You start a long task, close the tab, and come back to find the codespace stopped and the agent gone.

Claude Code works in Codespaces. Anthropic documents it, and the setup takes a few minutes. What surprises people is the lifecycle around it: an idle timer, a hard limit on how long a codespace runs, a login that disappears on rebuild, and a bill that counts hours whether or not the agent is doing anything. This post covers each one, from GitHub's and Anthropic's docs as of November 6, 2026. We build Sessionboxer, which runs agents in containers on your own machine, and the last section says where that fits and where Codespaces is the better choice.

Put Claude Code in the dev container

Anthropic ships Claude Code as a Dev Container Feature. The dev container docs give this minimal .devcontainer/devcontainer.json:

{
  "image": "mcr.microsoft.com/devcontainers/base:ubuntu",
  "features": {
    "ghcr.io/anthropics/devcontainer-features/claude-code:1.0": {}
  }
}

If your repository already has a devcontainer.json, add only the features entry. The :1.0 tag pins the install script, not the Claude Code version; the feature installs the latest release and Claude Code updates itself inside the container. In Codespaces the feature also adds the Claude Code VS Code extension. Then create the codespace and run claude in its terminal.

Logging in, and keeping the login

The first claude asks you to sign in through a browser. A codespace has no browser of its own, so the docs give the fallback: if no browser opens, or it signs you in and then shows a localhost connection error, copy the login URL shown above the terminal's paste prompt, sign in in your own browser, and paste the code it shows back into the terminal.

That login is stored under ~/.claude. Anthropic's docs say that in Codespaces this directory "persists when you stop and start a codespace but is cleared when you rebuild the container." GitHub's lifecycle page says the same from its side: a rebuild clears everything outside /workspaces. A new codespace starts with an empty home directory too.

To stop signing in every time, Anthropic suggests storing ANTHROPIC_API_KEY, or a CLAUDE_CODE_OAUTH_TOKEN made with claude setup-token, as a Codespaces secret. You add it under your GitHub settings, Codespaces, New secret, and pick which repositories can see it. Two details from GitHub's secrets docs and security page:

  • A new secret only reaches a codespace that is created or restarted after you add it.
  • Secrets are not copied in if you lack write access to the repository, or if the codespace was made from a pull request branch of a fork.

Why the codespace stops under the agent

Two timers stop a codespace, and they are easy to confuse.

The first is the idle timeout. It is 30 minutes by default and you can set it between 5 and 240 minutes in your settings, or per codespace with gh codespace create --idle-timeout 240m. An organization can set a lower maximum for its repositories. GitHub counts typing, the mouse, and terminal input or output as activity. While Claude Code prints to the terminal, the timer keeps resetting. A long step that prints nothing, like a test run with its output captured, gives the timer room to expire. Closing the browser tab does not stop a codespace; the timer does.

The second is the maximum lifetime. In GitHub's words, "a codespace has a maximum lifetime of 12 hours, regardless of your idle timeout policy or settings. This limit applies even while you are actively using the codespace." Near the limit you see a warning, and then the codespace stops. GitHub says that when a codespace stops, "any running processes are stopped," so the agent stops mid-turn.

After a stop, restart the codespace and continue the conversation with claude --continue; the files and ~/.claude are still there. Stopped codespaces are deleted after 30 days by default, "irrespective of whether a codespace contains unpushed changes." Push the agent's branch before you walk away, or use Keep codespace on github.com/codespaces.

What it costs

GitHub bills Codespaces for compute while a codespace is active and for storage while it exists. Personal accounts get a monthly quota; organization plans get none.

Plan Storage per month Compute per month
GitHub Free 15 GB-month 120 hours
GitHub Pro 20 GB-month 180 hours

Paid compute is $0.18 an hour on a 2-core machine and doubles with each step up to 32 cores. The pricing table lists an included usage multiplier equal to the core count, so the smallest machine uses the quota twice as fast as the hour count suggests. Your Claude subscription or API key is billed separately, as usual.

The warning on the timeout page matters for agents in particular: you pay for the whole time a codespace is active, "irrespective of whether you were using it." A four-hour idle timeout keeps a finished agent's machine billing for up to four hours. Stop the codespace when the task ends.

What the agent can reach in a codespace

The isolation is real. Each codespace runs on its own new virtual machine with its own network, and GitHub's firewall blocks incoming connections. Your laptop's files and SSH keys are not there. That makes a codespace a reasonable place to run Claude Code with fewer prompts, as long as you know what is inside the machine:

  • Outbound internet is open. GitHub's security page says codespaces "are allowed to make outbound connections to the internet."
  • The codespace gets a GitHub token with read and write access to the repository, if you have write access, plus any other repositories you authorized.
  • Any secret you added is an environment variable the agent can read, including the Claude token from the step above.

Anthropic's dev container page puts the risk plainly. With --dangerously-skip-permissions, a dev container does not stop a malicious project from sending out anything in the container, "including the Claude Code credentials stored in ~/.claude." Its advice is to use this only with repositories you trust. GitHub adds one more point: a repository's devcontainer.json can run arbitrary code through postCreateCommand when the codespace is built. Our post on keeping secrets away from a coding agent goes through what to leave out of reach.

Where Sessionboxer fits

Codespaces is a good choice when your team already uses dev containers, you have no machine that stays on, and your agent tasks fit inside a working day.

If those limits are the problem, the other way is to run the boxes on a machine you own. Sessionboxer puts each session in its own Docker container on your laptop or a server, and the agent runs without permission prompts inside it. A box keeps running until you stop it, and a stopped session resumes with its conversation, files and installed tools in place. The guide does not describe an idle timer or a lifetime limit; the limits are your machine's. It uses the Claude, ChatGPT, Cursor or other subscription you already have, with no Sessionboxer account.

GitHub works per session. A GitHub login added in Settings lets the box clone, push and open pull requests as that account; switch it off for a session and the login is gone from the box. With the Control Plane on HTTPS, a phone can get a push notification when a turn ends, so you do not need to keep a tab open.

What Sessionboxer does not do:

  • It does not give you cloud compute. The machine it runs on must stay on and have Docker, and each session gets 2 CPUs and 4 GB of memory by default.
  • It does not read your devcontainer.json. Sessions start from its own Sandbox image, and the agent installs what the project needs in the box.
  • The guide describes no outbound network filter for the box, and the agent can read the logins its session was given, as in a codespace.

If you want a server that stays on, our post on running Claude Code on a VPS compares three setups. For dev containers on your own machine, see Claude Code in a dev container or in Docker Sandboxes.

A short checklist

  1. Add the Claude Code feature to .devcontainer/devcontainer.json.
  2. Store CLAUDE_CODE_OAUTH_TOKEN from claude setup-token as a Codespaces secret for that repository only.
  3. Raise the idle timeout for agent work: gh codespace create --idle-timeout 240m.
  4. Plan long tasks around the 12-hour limit, and restart with claude --continue.
  5. Push the branch before you leave, and stop the codespace when the task is done.

Features mentioned

Keep reading