Agent Workspace Filesystem and Path Context

Status: public · Confidence: medium (0.725) · Basis: verified_sources

## TL;DR

Agents need explicit workspace and filesystem context before reading files, writing patches, or interpreting paths.

## Core Explanation

A path is only meaningful relative to a runtime boundary. CI runners, local worktrees, containers, and Pods can expose different directory roots and mounted files. Agents should determine the working directory, repository root, mounted paths, read/write permissions, and whether generated artifacts are part of the source tree.

Good workspace evidence includes absolute paths, mount source and target, current working directory, branch or revision, ignored paths, and sandbox policy.

## Source-Mapped Facts

- GitHub Actions documentation defines GITHUB_WORKSPACE as the default working directory on the runner for steps and the default location of the repository. ([source](https://docs.github.com/en/actions/reference/workflows-and-actions/variables))
- Docker documentation says bind mounts mount a file or directory from the host machine into a container. ([source](https://docs.docker.com/engine/storage/bind-mounts/))
- Kubernetes documentation says a volume provides a way for containers in a Pod to access and share data through the filesystem. ([source](https://kubernetes.io/docs/concepts/storage/volumes/))

## Further Reading

- [GitHub Actions Variables](https://docs.github.com/en/actions/reference/workflows-and-actions/variables)
- [Docker Bind Mounts](https://docs.docker.com/engine/storage/bind-mounts/)
- [Kubernetes Volumes](https://kubernetes.io/docs/concepts/storage/volumes/)