How mksglu/context-mode Handles Credential Passthrough for Authenticated CLIs

context-mode passes credential-bearing environment variables through to sandboxed subprocesses by filtering only a specific deny-list of dangerous variables, allowing GH_TOKEN, AWS_ACCESS_KEY_ID, and KUBECONFIG to authenticate CLIs like gh, aws, and kubectl automatically.

context-mode is a sandboxed execution environment that runs shell commands in isolated subprocesses. Unlike restrictive sandboxes that strip all environment variables, it employs a targeted sanitization strategy that preserves authentication tokens while blocking code-injection vectors.

The Sanitization Model in src/executor.ts

The credential passthrough mechanism centers on the private #buildSafeEnv method in src/executor.ts. Rather than constructing an allow-list that would break existing CLI authentication, the code copies the entire parent process.env and removes only entries present in a hardcoded DENIED Set.

How #buildSafeEnv Filters Variables

The method iterates over all environment variables and copies those that are neither undefined nor explicitly denied:

const env: Record<string, string> = {};
for (const [key, val] of Object.entries(process.env)) {
  if (val !== undefined && !DENIED.has(key) && !key.startsWith("BASH_FUNC_")) {
    env[key] = val;
  }
}
// forced sandbox overrides…

This loop ensures that any variable not appearing in the deny-list is preserved, including all standard cloud and GitHub credential variables.

The DENIED Set Contents

The deny-list enumerated in src/executor.ts focuses exclusively on exploit vectors that could alter execution behavior:

• LD_PRELOAD and DYLD_INSERT_LIBRARIES (dynamic library injection)
• PYTHONPATH (Python module shadowing)
• GIT_ASKPASS (credential helper hijacking)
• Other execution-modifying variables

Notably absent from DENIED are GH_TOKEN, GITHUB_TOKEN, AWS_ACCESS_KEY_ID, AWS_SECRET_ACCESS_KEY, and KUBECONFIG. Because these credential variables are not stripped, they flow directly into the sandboxed subprocess.

Authenticated CLI Execution Flow

When you invoke a command such as gh pr list or aws sts get-caller-identity, the executor follows a specific sequence:

1. Sanitization: #buildSafeEnv creates a safe environment object by filtering the parent environment against the DENIED Set.
2. Spawn: The executor calls spawn(command[0], command.slice(1), { cwd, env, … }) in src/executor.ts, passing the sanitized env object to the child process.
3. Authentication: Because credential variables survive the filtering process, the CLI binaries find their required tokens in process.env and authenticate exactly as they would outside the sandbox.

File-Based vs Environment-Based Credentials

While environment variables pass through transparently, file-based credentials face stricter controls. In src/security.ts, the security policy enforces:

fileGlobToRegex("**/*credentials*")

This blocks direct reads of files containing "credentials" in their path, preventing credential exfiltration via filesystem access. However, this restriction does not affect environment-variable-based authentication, allowing tools like kubectl (which reads KUBECONFIG) and aws (which reads AWS_ACCESS_KEY_ID) to function normally.

Practical Implementation Example

The following pattern demonstrates how authenticated commands execute within the sandbox:

// Host environment already exports:
// export GH_TOKEN=ghp_abcdef...
// export AWS_ACCESS_KEY_ID=AKIA...
// export AWS_SECRET_ACCESS_KEY=xyz...

await executor.execute({
  language: "shell",
  code: "gh auth status && aws sts get-caller-identity && kubectl config view",
});

Inside the sandbox, GH_TOKEN, AWS_ACCESS_KEY_ID, AWS_SECRET_ACCESS_KEY, and KUBECONFIG remain present in the environment, enabling each CLI to authenticate to its respective service without additional configuration.

Summary

• Credential passthrough is intentional: By copying the entire parent environment and removing only a targeted deny-list, context-mode preserves authentication tokens.
• The deny-list is security-focused: Only variables that could alter execution or inject code (like LD_PRELOAD and GIT_ASKPASS) are stripped; cloud credentials are explicitly allowed.
• File-based leaks are mitigated: The security policy in src/security.ts blocks reads of files matching *credentials*, but this does not interfere with environment-variable authentication.
• Zero configuration required: CLIs like gh, aws, and kubectl work out-of-the-box because they rely on environment variables that survive sanitization.

Frequently Asked Questions

Does context-mode require special configuration to use the AWS CLI?

No special configuration is required. As long as AWS_ACCESS_KEY_ID and AWS_SECRET_ACCESS_KEY are present in the host environment when the executor starts, they are automatically passed through to the sandboxed subprocess. The CLI authenticates using these variables exactly as it does outside the sandbox.

Is KUBECONFIG automatically available inside the sandbox?

Yes. The KUBECONFIG environment variable is not included in the DENIED Set defined in src/executor.ts, so it is copied unchanged into the child process environment. However, note that if your kubeconfig file path contains "credentials", the file-read policy in src/security.ts may block direct file access depending on the specific security rules applied.

Why does the deny-list include GIT_ASKPASS but not GH_TOKEN?

GIT_ASKPASS is excluded because it specifies a command that Git executes to request credentials, which could be exploited to run arbitrary code inside the sandbox. GH_TOKEN is a passive data variable containing a bearer token, which poses no execution risk. The deny-list targets execution vectors, not credential data itself.

Can malicious code running in the sandbox steal my AWS credentials?

Malicious code can read the AWS_ACCESS_KEY_ID and AWS_SECRET_ACCESS_KEY variables from process.env inside the sandbox, as these are passed through to enable CLI functionality. However, the sandbox prevents reading credential files from disk via the **/*credentials* file glob restriction. You should treat the sandbox as having access to any credential present in the parent environment, and only pass through secrets that the specific CLI command requires.

{
  "mcpServers": {
    "instagit": {
      "command": "npx",
      "args": ["-y", "instagit@latest"]
    }
  }
}