Current Working Directory (cwd)

What cwd Means in Practice

The current working directory is the process or shell location that relative paths resolve against. It is a deceptively small piece of runtime state, but it changes which files a command, script or tool can see and modify.

Because cwd is process-local, two invocations of the same command can behave differently if they start in different directories. That is why build steps, automation jobs and interactive shells often fail in ways that look like missing files, but are actually path-resolution mistakes.

Why cwd Matters for Scripts and Automation

cwd is a dependency for almost every file-relative operation, including reading configuration, writing outputs, loading templates and finding local modules. A script that assumes a fixed starting directory can work on a developer laptop and break in CI, containers or task runners.

Tooling authors therefore need to decide whether a command should honour the caller's cwd or normalise paths internally. The wrong choice can produce fragile automation, accidental file placement, or inconsistent behaviour when the same tool is launched from different directories.

cwd and Access to Local Files

cwd does not itself grant permission, but it changes which pathname a program asks the operating system to open. If a program uses relative paths for sensitive operations, a user or upstream process can steer it toward a different file than the developer intended.

This is especially important in security-sensitive workflows where a relative path could resolve to a local secret, a malicious replacement file, or an output location that was never meant to be writable. The issue is usually not the directory state alone, but the trust placed in path assumptions.

How to Think About cwd Safely

Good practice is to treat cwd as untrusted input to the runtime environment. Robust tools resolve critical paths explicitly, validate where reads and writes will land, and avoid assuming that the caller started in a particular directory.

When a command must operate relative to a project root, it should establish that root deliberately rather than inheriting an arbitrary launch location. That keeps behaviour predictable across shells, schedulers, containers and service wrappers.

Risk and Threat Considerations

cwd creates risk when security-relevant file access depends on relative paths. A process that opens configuration, scripts, imports or output files from its working directory can be redirected into the wrong file tree, which may cause data loss, configuration drift, or unintended execution of attacker-controlled content.

Failure mechanism: The program trusts relative resolution, then a different cwd changes which file path is actually opened, written or executed. In compromised or misconfigured environments, that can turn an ordinary path lookup into file substitution, path confusion, or exposure of local data.

Impact: The result can be silent corruption, unexpected privilege use, leakage of nearby files, broken automation, or execution of the wrong artifact. In build and orchestration pipelines, this often appears as a reliability issue first and a security issue second.

Practitioner Guidance

What to watch for: Review any command, script or service that depends on relative paths, especially when it reads secrets, writes artifacts, loads plugins, or launches child processes. If the outcome changes based on launch location, the cwd assumption needs to be made explicit.

Governance implication: Treat cwd-dependent behaviour as part of operational hardening, not just developer convenience. Standardise how entrypoints discover the project root, and prefer explicit absolute paths for sensitive file operations.

Related resources from NHI Mgmt Group

• What breaks when a GitHub Action extracts artifacts into the current working directory by default?
• Current Working Directory Restriction
• Current Working Directory DLL Planting
• How do security teams know if Active Directory hardening is actually working?