Store session state under project `.copilot/` directory to support ephemeral home directories (Docker, CI, devcontainers)

[ao2]

Problem

When running Copilot CLI inside a Docker container, devcontainer, or CI runner, the home directory (~/.copilot/session-state/) is ephemeral — it is lost when the container exits. This makes /session restore SESSION_ID permanently unavailable after the container shuts down, even if the working project directory is a persistent volume mount or git checkout.

The session state that gets lost includes:

• The event log (events.jsonl) needed for session restore
• Checkpoints and their index
• Any session artifacts written to the session folder

Proposed solution

Allow the runtime to store (or mirror) session state under a .copilot/session-state/ directory inside the project working directory, rather than exclusively under ~/.copilot/session-state/.

A reasonable implementation:

1. If a .copilot/ directory exists in the current working directory when a session starts, store session state there instead of (or in addition to) ~/.copilot/session-state/.
2. When resolving a session ID for /session restore, also search .copilot/session-state/ in the cwd.
3. Optionally: support a config option or environment variable (e.g. COPILOT_SESSION_DIR) to explicitly override the storage root.

The .copilot/ directory in the project can already be used as home for agent-created artifacts (like plan.md). Keeping session state there as well makes the whole session context co-located with the code it relates to, and committable to git if desired.

Relation to existing issues

Issue #1947 requests cloud-synced sessions for cross-device continuity. This request is narrower — it only requires the runtime to look in an additional local directory, with no network dependency.

Environment

Any environment where $HOME is not persistent: Docker containers, GitHub Codespaces rebuilds, CI runners, devcontainers.

Suggested label: area:sessions

[ao2]

A possible workaround would be to share ~/.copilot/session-state/ in the container environment, but that would also expose all the sessions from other projects, which might not be ideal in case one only wants to tie one container to a specific project.

So I think supporting project-specific session state may still be useful.