Run Command - #843
Conversation
Signed-off-by: trewc456-ai <trewc456@gmail.com>
Signed-off-by: trewc456-ai <trewc456@gmail.com>
Signed-off-by: trewc456-ai <trewc456@gmail.com>
Signed-off-by: trewc456-ai <trewc456@gmail.com>
Signed-off-by: trewc456-ai <trewc456@gmail.com>
Signed-off-by: trewc456-ai <trewc456@gmail.com>
📝 WalkthroughWalkthroughAdds repository security policy, automated CodeQL, DevSkim, SonarCloud, and Jscrambler workflows, Dev Container enforcement controls, and VS Code GitHub MCP configuration. ChangesSecurity controls and scanning
Developer MCP setup
Estimated code review effort: 3 (Moderate) | ~20 minutes 🚥 Pre-merge checks | ✅ 4 | ❌ 1❌ Failed checks (1 inconclusive)
✅ Passed checks (4 passed)
✨ Finishing Touches🧪 Generate unit tests (beta)
Warning There were issues while running some tools. Please review the errors and either fix the tool's configuration or disable the tool if it's a critical failure. 🔧 Checkov (3.3.8).devcontainer/devcontainer.jsonTraceback (most recent call last): .github/workflows/codeql.ymlTraceback (most recent call last): .github/workflows/devskim.ymlTraceback (most recent call last):
🔧 Biome (2.5.3).devcontainer/devcontainer.jsonFile contains syntax errors that prevent linting: Line 4: unexpected character ... [truncated 736 characters] ... ouble quoted.; Line 8: unexpected character Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment Warning |
trewc456-ai
left a comment
There was a problem hiding this comment.
Run Selected Repositories
|
| uses: actions/checkout@v4 | ||
|
|
||
| - name: Run DevSkim scanner | ||
| uses: microsoft/DevSkim-Action@v1 |
| - uses: actions/setup-node@v4 | ||
| with: | ||
| node-version: 20 | ||
| - run: npm ci |
trewc456-ai
left a comment
There was a problem hiding this comment.
Test Functions of Commands
There was a problem hiding this comment.
Actionable comments posted: 5
🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
Inline comments:
In @.devcontainer/devcontainer.json:
- Around line 4-12: Restore valid JSON in the devcontainer configuration by
removing the appended Anti-Bypass Controls Markdown after the closing object.
Move that policy text into SECURITY.md or another appropriate Markdown document,
preserving its contents there.
In @.github/workflows/jscrambler-code-integrity.yml:
- Around line 14-19: Update the workflow trigger or protection-step condition so
Jscrambler protection runs only for trusted pushes or same-repository pull
requests, preventing fork PRs from reaching the secrets-dependent protect
action. Preserve execution for pushes to master and eligible internal pull
requests, using the existing Jscrambler protection step as the change point.
In @.github/workflows/sonarcloud.yml:
- Around line 46-59: Update the SonarCloud workflow job to grant read access to
repository contents, check out the repository with fetch-depth 0, and replace
the archived sonarcloud-github-action reference with the maintained SonarSource
scan action. Set non-empty, repository-specific values for sonar.projectKey and
sonar.organization so the analysis can run.
In @.vscode/mcp.json:
- Around line 14-15: Update the MCP Docker configuration to remove the
GITHUB_PERSONAL_ACCESS_TOKEN environment assignment from the docker run
arguments and define it through the configuration’s env mapping instead,
preserving the existing ${input:token} reference and Docker behavior.
In `@SECURITY.md`:
- Around line 15-21: Replace the placeholder content in the “Reporting a
Vulnerability” section with a concrete private reporting process, including a
secure contact channel, acknowledgement timeframe, and expected handling or
disclosure outcomes for accepted and declined reports.
🪄 Autofix (Beta)
Fix all unresolved CodeRabbit comments on this PR:
- Push a commit to this branch (recommended)
- Create a new PR with the fixes
ℹ️ Review info
⚙️ Run configuration
Configuration used: Organization UI
Review profile: CHILL
Plan: Pro Plus
Run ID: adc1cec1-dc76-4016-9701-bdc3827feca9
📒 Files selected for processing (8)
.devcontainer/devcontainer.json.github/workflows/codeql.yml.github/workflows/devskim.yml.github/workflows/jscrambler-code-integrity.yml.github/workflows/sonarcloud.yml.vscode/mcp.json.vscode/settings.jsonSECURITY.md
| }## Anti-Bypass Controls | ||
|
|
||
| - Enforce server-side authorization for every status transition. | ||
| - Require signed applicant attestation before readiness review. | ||
| - Treat `auto_approved_for_submission_readiness` as internal-only and non-legal. | ||
| - Block direct client-side updates to compliance, submission, or approval fields. | ||
| - Record immutable audit logs for all document uploads, verification checks, and reviewer actions. | ||
| - Require manual compliance override for any high-risk mismatch. | ||
| - Store final status transitions through a backend workflow service only. |
There was a problem hiding this comment.
🎯 Functional Correctness | 🔴 Critical | ⚡ Quick win
Restore valid JSON before this Dev Container can load.
Line 4 closes the JSON object, then appends Markdown policy text. JSON parsing fails, so the Dev Container configuration—and the stated controls—cannot be used. Move the policy to SECURITY.md or another Markdown document.
Proposed fix
{
"image": "mcr.microsoft.com/devcontainers/universal:2",
"features": {}
-}## Anti-Bypass Controls
-
-- Enforce server-side authorization for every status transition.
-- Require signed applicant attestation before readiness review.
-- Treat `auto_approved_for_submission_readiness` as internal-only and non-legal.
-- Block direct client-side updates to compliance, submission, or approval fields.
-- Record immutable audit logs for all document uploads, verification checks, and reviewer actions.
-- Require manual compliance override for any high-risk mismatch.
-- Store final status transitions through a backend workflow service only.
+}📝 Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.
| }## Anti-Bypass Controls | |
| - Enforce server-side authorization for every status transition. | |
| - Require signed applicant attestation before readiness review. | |
| - Treat `auto_approved_for_submission_readiness` as internal-only and non-legal. | |
| - Block direct client-side updates to compliance, submission, or approval fields. | |
| - Record immutable audit logs for all document uploads, verification checks, and reviewer actions. | |
| - Require manual compliance override for any high-risk mismatch. | |
| - Store final status transitions through a backend workflow service only. | |
| } |
🧰 Tools
🪛 Biome (2.5.3)
[error] 4-4: unexpected character #
(parse)
[error] 4-4: unexpected character #
(parse)
[error] 4-4: String values must be double quoted.
(parse)
[error] 4-4: Minus must be followed by a digit
(parse)
[error] 4-4: String values must be double quoted.
(parse)
[error] 4-4: String values must be double quoted.
(parse)
[error] 6-6: Minus must be followed by a digit
(parse)
[error] 6-6: String values must be double quoted.
(parse)
[error] 6-6: String values must be double quoted.
(parse)
[error] 6-6: Minus must be followed by a digit
(parse)
[error] 6-6: String values must be double quoted.
(parse)
[error] 6-6: String values must be double quoted.
(parse)
[error] 6-6: String values must be double quoted.
(parse)
[error] 6-6: String values must be double quoted.
(parse)
[error] 6-6: String values must be double quoted.
(parse)
[error] 6-6: String values must be double quoted.
(parse)
[error] 6-6: unexpected character .
(parse)
[error] 7-7: Minus must be followed by a digit
(parse)
[error] 7-7: String values must be double quoted.
(parse)
[error] 7-7: String values must be double quoted.
(parse)
[error] 7-7: String values must be double quoted.
(parse)
[error] 7-7: String values must be double quoted.
(parse)
[error] 7-7: String values must be double quoted.
(parse)
[error] 7-7: String values must be double quoted.
(parse)
[error] 7-7: String values must be double quoted.
(parse)
[error] 7-7: unexpected character .
(parse)
[error] 8-8: Minus must be followed by a digit
(parse)
[error] 8-8: String values must be double quoted.
(parse)
[error] 8-8: unexpected character ```
(parse)
[error] 8-8: String values must be double quoted.
(parse)
[error] 8-8: unexpected character ```
(parse)
[error] 8-8: String values must be double quoted.
(parse)
[error] 8-8: String values must be double quoted.
(parse)
[error] 8-8: Minus must be followed by a digit
(parse)
[error] 8-8: String values must be double quoted.
(parse)
[error] 8-8: String values must be double quoted.
(parse)
[error] 8-8: String values must be double quoted.
(parse)
[error] 8-8: Minus must be followed by a digit
(parse)
[error] 8-8: String values must be double quoted.
(parse)
[error] 8-8: unexpected character .
(parse)
[error] 9-9: Minus must be followed by a digit
(parse)
[error] 9-9: String values must be double quoted.
(parse)
[error] 9-9: String values must be double quoted.
(parse)
[error] 9-9: String values must be double quoted.
(parse)
[error] 9-9: Minus must be followed by a digit
(parse)
[error] 9-9: String values must be double quoted.
(parse)
[error] 9-9: String values must be double quoted.
(parse)
[error] 9-9: String values must be double quoted.
(parse)
[error] 9-9: String values must be double quoted.
(parse)
[error] 9-12: End of file expected
(parse)
[error] 9-9: unexpected character .
(parse)
[error] 10-10: Minus must be followed by a digit
(parse)
[error] 10-10: unexpected character .
(parse)
[error] 11-11: Minus must be followed by a digit
(parse)
[error] 11-11: Minus must be followed by a digit
(parse)
[error] 11-11: unexpected character .
(parse)
[error] 12-12: Minus must be followed by a digit
(parse)
[error] 12-12: unexpected character .
(parse)
🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
In @.devcontainer/devcontainer.json around lines 4 - 12, Restore valid JSON in
the devcontainer configuration by removing the appended Anti-Bypass Controls
Markdown after the closing object. Move that policy text into SECURITY.md or
another appropriate Markdown document, preserving its contents there.
Source: Linters/SAST tools
| on: | ||
| push: | ||
| branches: [ "master" ] | ||
| pull_request: | ||
| # The branches below must be a subset of the branches above | ||
| branches: [ "master" ] |
There was a problem hiding this comment.
🩺 Stability & Availability | 🟠 Major | ⚡ Quick win
🧩 Analysis chain
🏁 Script executed:
#!/bin/bash
set -euo pipefail
echo "== workflow files =="
git ls-files '.github/workflows/*' || true
echo "== target workflow =="
if [ -f .github/workflows/jscrambler-code-integrity.yml ]; then
cat -n .github/workflows/jscrambler-code-integrity.yml
else
echo "missing"
fi
echo "== searches for Jscrambler secrets / steps =="
rg -n "jscrambler|JSCRAMBLER|applicationId|apiSecret|accessToken|pull_request|pull_request_target" .github/workflows || true
echo "== checkout default refs settings in workflows =="
rg -n "actions/checkout|ref:|pull_request_target|pull_request\)" .github/workflows || trueRepository: dbpedia/extraction-framework
Length of output: 5274
🌐 Web query:
GitHub Actions pull_request fork secrets not passed to workflows pull_request_target forks
💡 Result:
GitHub Actions intentionally restricts secret access and modifies permissions for pull requests originating from forks to prevent security compromises [1][2]. Understanding how different events handle these security boundaries is critical for secure CI/CD pipelines. The pull_request Event When a workflow is triggered by the pull_request event for a pull request from a fork, GitHub runs the workflow using the code from the pull request's merge commit [1][3]. Because this code is provided by an untrusted source, GitHub enforces the following security restrictions: - Secrets are not made available to the workflow [1][4][2]. - The GITHUB_TOKEN is granted read-only permissions [1][2]. These measures ensure that even if an attacker submits malicious code, they cannot access your repository secrets or tamper with your repository using the workflow's identity [1][5]. The pull_request_target Event The pull_request_target event is designed to allow workflows to interact with pull requests from forks by running in the context of the base repository rather than the pull request's commit [1][3][5]. Because it runs code from your base repository's default branch, it is granted: - Access to repository and organization secrets [1][6][7]. - A GITHUB_TOKEN with elevated (often write-level) permissions [1][6]. Security Risk: The "Pwn Request" Using pull_request_target creates a significant security risk if the workflow proceeds to check out or execute the untrusted code from the incoming pull request [6][5][8]. If a workflow uses actions/checkout to pull the head commit of a fork, it exposes your secrets and write permissions to whatever malicious commands might be in that fork—a vulnerability often referred to as a "pwn request" [6][5]. Best Practices for Secure Automation - Avoid checking out untrusted code in pull_request_target workflows [6][8]. Reserve this event for metadata-only operations, such as labeling, commenting, or triage [1][6][5]. - For CI tasks that require running tests or building code, use the pull_request event [5]. Since this event does not provide secrets, consider a "Trusted Bridge" pattern: use one workflow (triggered by pull_request) to run tests and output artifacts, and a second, highly-restricted workflow (triggered by workflow_run) to consume those artifacts and perform privileged tasks like posting status checks or comments [6][8]. - If you must use pull_request_target, ensure the workflow is strictly gated by manual approval (e.g., waiting for a specific label applied by a maintainer) and minimize the token permissions using the permissions block [9][6][7].
Citations:
- 1: https://docs.github.com/en/actions/reference/security/securely-using-pull_request_target
- 2: https://github.com/github/docs/blob/962a1c8dccb8c0f66548b324e5b921b5e4fbc3d6/content/actions/security-for-github-actions/security-guides/security-hardening-for-github-actions.md
- 3: https://docs.github.com/en/enterprise-server@3.19/actions/reference/security/securely-using-pull_request_target
- 4: https://www.devhide.com/how-to-make-github-actions-safely-access-secrets-for-prs-created-from-forks-76952023
- 5: https://devencyclopedia.com/blog/github-actions-security
- 6: https://medium.com/@dannytt/the-hidden-risk-in-your-ci-pipeline-why-pull-request-target-is-a-security-liability-3b83ce08dce7
- 7: https://medium.com/@zs84907/the-missing-acl-in-github-actions-securing-pull-request-target-with-ok-to-test-3298682655dd
- 8: https://github.com/github/docs/blob/main/content/actions/reference/security/secure-use.md
- 9: https://stackoverflow.com/questions/76952023/how-to-make-github-actions-safely-access-secrets-for-prs-created-from-forks
Skip Jscrambler protection for fork pull requests.
pull_request branches, including fork PRs, do not make Actions secrets available. This workflow passes jscrambler/code-integrity-actions/protect@... three Jscrambler secrets, so fork PRs reach the protected step with missing credentials and fail. Restrict the workflow to trusted pushes, or make the step conditional on same-repository PRs.
🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
In @.github/workflows/jscrambler-code-integrity.yml around lines 14 - 19, Update
the workflow trigger or protection-step condition so Jscrambler protection runs
only for trusted pushes or same-repository pull requests, preventing fork PRs
from reaching the secrets-dependent protect action. Preserve execution for
pushes to master and eligible internal pull requests, using the existing
Jscrambler protection step as the change point.
| - name: Analyze with SonarCloud | ||
|
|
||
| # You can pin the exact commit or the version. | ||
| # uses: SonarSource/sonarcloud-github-action@v2.2.0 | ||
| uses: SonarSource/sonarcloud-github-action@4006f663ecaf1f8093e8e4abb9227f6041f52216 | ||
| env: | ||
| SONAR_TOKEN: ${{ secrets.SONAR_TOKEN }} # Generate a token on Sonarcloud.io, add it to the secrets of this repo with the name SONAR_TOKEN (Settings > Secrets > Actions > add new repository secret) | ||
| with: | ||
| # Additional arguments for the SonarScanner CLI | ||
| args: | ||
| # Unique keys of your project and organization. You can find them in SonarCloud > Information (bottom-left menu) | ||
| # mandatory | ||
| -Dsonar.projectKey= | ||
| -Dsonar.organization= |
There was a problem hiding this comment.
🎯 Functional Correctness | 🟠 Major | 🏗️ Heavy lift
🧩 Analysis chain
🏁 Script executed:
#!/bin/bash
set -euo pipefail
echo "== workflow files =="
git ls-files .github/workflows || true
echo "== sonar workflow =="
if [ -f .github/workflows/sonarcloud.yml ]; then
cat -n .github/workflows/sonarcloud.yml
fi
echo "== search sonar actions/checkouts =="
rg -n "SonarSource/sonarcloud-github-action|github\.com/sonarsource/sonarcloud-github-action|checkout|permissions:|contents: read|sonar.projectKey|sonar.organization" .github/workflows . 2>/dev/null | head -200Repository: dbpedia/extraction-framework
Length of output: 6740
🌐 Web query:
SonarSource sonarcloud-github-action archived check out code before running scan contents read
💡 Result:
The sonarcloud-github-action repository has been archived by SonarSource and is now read-only [1][2]. You should migrate to the sonarqube-scan-action, which serves as the official, unified, and drop-in replacement for both SonarQube and SonarCloud scanning in GitHub Actions [3][4][5]. Regarding the check out step: It is standard practice and highly recommended to check out your code before running the scan [6][4][7]. When performing the checkout, you must disable shallow clones by setting fetch-depth: 0 [6][4][7]. This is critical because SonarCloud requires the full git history (including git blame information) to correctly attribute code and detect issues in new code [8][7]. Example workflow configuration: jobs: sonarqube: runs-on: ubuntu-latest steps: - uses: actions/checkout@v4 with: fetch-depth: 0 - name: SonarQube Scan uses: SonarSource/sonarqube-scan-action@v4 env: SONAR_TOKEN: ${{ secrets.SONAR_TOKEN }}
Citations:
- 1: https://github.com/sonarsource/sonarcloud-github-action/releases
- 2: https://github.com/sonarsource/sonarcloud-github-action
- 3: https://github.com/SonarSource/sonarcloud-github-action/blob/master/README.md
- 4: https://github.com/marketplace/actions/official-sonarqube-scan
- 5: https://docs.sonarsource.com/sonarqube-cloud/analyzing-source-code/ci-based-analysis/github-actions-for-sonarcloud.md
- 6: https://github.com/SonarSource/sonarqube-scan-action/?tab=readme-ov-file
- 7: https://github.com/SonarSource/sonarqube-scan-action/blob/master/README.md
- 8: https://github.com/libfn/functional/blob/a917922844b74d72bf735bf32855184df02f3aaa/.github/workflows/sonarcloud-pr-scan.yml
🌐 Web query:
SonarSource sonarcloud-github-action is archived status on GitHub
💡 Result:
Yes, the SonarSource/sonarcloud-github-action repository on GitHub is officially archived [1][2]. As of October 22, 2025, the repository was archived by the owner and is now in a read-only state [2]. This action has been deprecated in favor of sonarqube-scan-action [1][3]. SonarSource has established sonarqube-scan-action as a unified, drop-in replacement that supports scanning with both SonarQube Server and SonarQube Cloud [2][3]. Users are strongly encouraged to migrate their CI/CD workflows to this newer action to ensure continued support and compatibility [2][4].
Citations:
- 1: https://github.com/SonarSource/sonarcloud-github-action
- 2: https://github.com/sonarsource/sonarcloud-github-action/releases
- 3: https://github.com/SonarSource/sonarqube-scan-action/?tab=readme-ov-file
- 4: Update reusable action version to latest available SonarSource/sonarcloud-github-action#101
Configure the SonarCloud workflow so it can run analysis.
This job still uses the archived sonarcloud-github-action, omits contents: 读 checkout access, and passes blank -Dsonar.projectKey= / -Dsonar.organization= values. Add checkout with fetch-depth: 0, grant contents: 读, migrate to the maintained SonarSource scan action, and fill in real SonarCloud keys.
🧰 Tools
🪛 zizmor (1.26.1)
[warning] 50-50: action or reusable workflow from archived repository (archived-uses): repository is archived
(archived-uses)
🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
In @.github/workflows/sonarcloud.yml around lines 46 - 59, Update the SonarCloud
workflow job to grant read access to repository contents, check out the
repository with fetch-depth 0, and replace the archived sonarcloud-github-action
reference with the maintained SonarSource scan action. Set non-empty,
repository-specific values for sonar.projectKey and sonar.organization so the
analysis can run.
Source: Linters/SAST tools
| "-e", | ||
| "GITHUB_PERSONAL_ACCESS_TOKEN=${input:token}", |
There was a problem hiding this comment.
🔒 Security & Privacy | 🟠 Major | ⚡ Quick win
🧩 Analysis chain
🏁 Script executed:
#!/bin/bash
set -euo pipefail
echo "== locate mcp.json =="
git ls-files | grep -F '.vscode/mcp.json' || true
echo "== .vscode/mcp.json =="
if [ -f .vscode/mcp.json ]; then
cat -n .vscode/mcp.json
fi
echo "== search docker MCP configs =="
git ls-files | xargs grep -l 'docker run\|github-mcp-server\|GITHUB_PERSONAL_ACCESS_TOKEN' 2>/dev/null || true
echo "== relevant shell/config snippets =="
rg -n 'docker run|GITHUB_PERSONAL_ACCESS_TOKEN|github-mcp-server|args:|env:' .github .vscode vscode 2>/dev/null || trueRepository: dbpedia/extraction-framework
Length of output: 1612
🌐 Web query:
GitHub MCP server Docker run environment variable token args command line process list GITHUB_PERSONAL_ACCESS_TOKEN
💡 Result:
To run the official GitHub MCP server using Docker, you must use the image hosted at ghcr.io/github/github-mcp-server [1][2][3]. The previous npm package (@modelcontextprotocol/server-github) is deprecated [4][2]. Required Environment Variable The server requires a GitHub Personal Access Token (PAT) to authenticate with the GitHub API [5][1][2]. You must pass this as an environment variable named GITHUB_PERSONAL_ACCESS_TOKEN [5][1]. Example Docker Command You can run the server directly via the command line using the following Docker command [5][1]: docker run -i --rm \ -e GITHUB_PERSONAL_ACCESS_TOKEN= \ ghcr.io/github/github-mcp-server Configuration in MCP Host Files If you are configuring the server within an MCP host configuration file (such as for Claude or other MCP-compatible IDEs), the command is structured as follows [1][3]: { "mcpServers": { "github": { "command": "docker", "args": [ "run", "-i", "--rm", "-e", "GITHUB_PERSONAL_ACCESS_TOKEN", "ghcr.io/github/github-mcp-server" ], "env": { "GITHUB_PERSONAL_ACCESS_TOKEN": "<YOUR_TOKEN>" } } } } Additional Configuration Options - Custom Toolsets: You can customize which toolsets are enabled by passing additional environment variables such as GITHUB_TOOLSETS or enabling dynamic toolsets with GITHUB_DYNAMIC_TOOLSETS=1 [5][6]. - GitHub Enterprise: If using GitHub Enterprise, you can specify the host by setting the GITHUB_HOST environment variable [1]. Ensure that your Docker environment is running, and if you encounter pull errors, ensure you are authenticated to the GitHub Container Registry (ghcr.io) or that your network allows public access to the image [1][2][3].
Citations:
- 1: https://github.com/github/github-mcp-server
- 2: https://github.com/github/github-mcp-server/tree/main/docs/installation-guides
- 3: https://github.com/github/github-mcp-server/blob/d0320b870d6a4a090378b4f28bb1f0f1bfe5406e/README.md
- 4: https://www.npmjs.com/package/@modelcontextprotocol/server-github
- 5: https://github.com/meingst/github-mcp-server
- 6: https://github.com/botkevin/github-mcp-server
🌐 Web query:
VS Code MCP configuration shell environment variables env command args ${input:...}
💡 Result:
In Visual Studio Code, MCP (Model Context Protocol) server configurations are managed via an mcp.json file located either in your workspace (.vscode/mcp.json) or your user profile [1][2][3]. Configuration Structure and Input Variables The configuration uses an inputs array to define sensitive information (like API keys) that can be reused across server configurations [2][4][3]. You can reference these defined inputs using the ${input:variable-id} syntax within your configuration [2][4][3]. Example Configuration In your mcp.json file, you can define inputs and reference them in the env or headers fields [2][3]: { "inputs": [ { "type": "promptString", "id": "api-key", "description": "Enter your API key" } ], "servers": { "my-server": { "type": "stdio", "command": "npx", "args": ["-y", "@example/mcp-server"], "env": { "API_KEY": "${input:api-key}" } } } } Key Configuration Fields - command: The executable used to start the server (e.g., npx, node, python) [2][3]. - args: An optional array of arguments passed to the command [2][3]. - env: An object defining environment variables for the server process [2][3]. - envFile: An optional path to an environment file (e.g., "${workspaceFolder}/.env") to load additional variables [2][3]. - cwd: The working directory for the command, which defaults to the workspace folder [3]. For remote servers (type: http or sse), you can similarly use ${input:...} in the headers field for authentication [2][3]. VS Code provides IntelliSense within mcp.json to assist with this schema [1][2][3].
Citations:
- 1: https://code.visualstudio.com/docs/copilot/customization/mcp-servers
- 2: https://github.com/microsoft/vscode-docs/blob/36ba054f/docs/copilot/reference/mcp-configuration.md
- 3: https://code.visualstudio.com/docs/copilot/reference/mcp-configuration
- 4: https://github.com/microsoft/vscode-docs/blob/main/docs/copilot/reference/mcp-configuration.md
🌐 Web query:
VS Code MCP shell environment variables "MCP shell" "env" "command" "args" "${input"
💡 Result:
In the Model Context Protocol (MCP) ecosystem, particularly when configured for applications like Claude Desktop or VS Code-based MCP clients, environment variables and command arguments are managed via the client's configuration file (e.g., claude_desktop_config.json) [1]. There is no universal "MCP shell env command" syntax; instead, the configuration relies on specific env and args fields within the MCP server definition [1][2]. Configuration Patterns: 1. Environment Variables: These are defined in the env object within the server configuration [1][2]. Some implementations support referencing existing shell environment variables using the ${VAR_NAME} syntax [1][3]. { "mcpServers": { "my-server": { "command": "python3", "args": ["server.py"], "env": { "API_KEY": "${MY_API_KEY_ENV_VAR}" } } } } 2. Command Arguments: Arguments are passed as an array of strings in the args field [1][2]. These are passed directly to the command process [2]. 3. Shell Execution: If you are using a specific "shell" MCP server (such as mcp-shell-server or shell-mcp), note that these servers typically execute commands as direct subprocesses (argv-based) rather than invoking a full shell [4][2]. This means shell-specific features like glob expansion, pipe operators (|), or environment variable expansion may not work unless explicitly implemented by that specific server [4][2]. 4. Input/Arguments handling: While some tools or proxy systems allow passing JSON parameters as arguments or environment variables [5][6], these are usually handled at the application layer or via specific flags defined by the tool's implementation rather than the core MCP protocol itself [5][2]. If you are encountering ${input in a configuration context, it is likely intended to be a placeholder for dynamic parameter injection supported by a specific client or proxy layer, rather than a standard MCP protocol feature [5]. Check the documentation for the specific MCP server or proxy you are using, as they define how inputs are mapped to command arguments or environment variables [2].
Citations:
- 1: https://calmops.com/ai/model-context-protocol-mcp-complete-guide/
- 2: https://claudemarketplaces.com/mcp/tumf/mcp-shell-server
- 3: https://fastmcp.wiki/en/deployment/server-configuration
- 4: https://crates.io/crates/shell-mcp
- 5: https://raw.githubusercontent.com/f/mcptools/master/README.md
- 6: http://github.com/f/mcptools
Do not pass the PAT in Docker’s command-line arguments.
Expanding ${input:token} into -e GITHUB_PERSONAL_ACCESS_TOKEN=... puts the PAT into docker run arguments, where it can be visible through process/terminal diagnostics. Use VS Code MCP’s env mapping, which supports ${input:...} and matches the recommended official Docker configuration.
Proposed fix
"-e",
- "GITHUB_PERSONAL_ACCESS_TOKEN=${input:token}",
+ "GITHUB_PERSONAL_ACCESS_TOKEN",
"ghcr.io/github/github-mcp-server:1.6.0"
- ],
+ ],
+ "env": {
+ "GITHUB_PERSONAL_ACCESS_TOKEN": "${input:token}"
+ },📝 Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.
| "-e", | |
| "GITHUB_PERSONAL_ACCESS_TOKEN=${input:token}", | |
| "-e", | |
| "GITHUB_PERSONAL_ACCESS_TOKEN", | |
| "ghcr.io/github/github-mcp-server:1.6.0" | |
| ], | |
| "env": { | |
| "GITHUB_PERSONAL_ACCESS_TOKEN": "${input:token}" | |
| }, |
🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
In @.vscode/mcp.json around lines 14 - 15, Update the MCP Docker configuration
to remove the GITHUB_PERSONAL_ACCESS_TOKEN environment assignment from the
docker run arguments and define it through the configuration’s env mapping
instead, preserving the existing ${input:token} reference and Docker behavior.
| ## Reporting a Vulnerability | ||
|
|
||
| Use this section to tell people how to report a vulnerability. | ||
|
|
||
| Tell them where to go, how often they can expect to get an update on a | ||
| reported vulnerability, what to expect if the vulnerability is accepted or | ||
| declined, etc. |
There was a problem hiding this comment.
🔒 Security & Privacy | 🟠 Major | ⚡ Quick win
Provide an actual private vulnerability-reporting process.
This placeholder gives reporters no contact channel, acknowledgement timeframe, or disclosure process. Replace it before publishing the policy; otherwise vulnerabilities cannot be reported through a defined private path.
🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
In `@SECURITY.md` around lines 15 - 21, Replace the placeholder content in the
“Reporting a Vulnerability” section with a concrete private reporting process,
including a secure contact channel, acknowledgement timeframe, and expected
handling or disclosure outcomes for accepted and declined reports.


Description
Motivation and Context
How Has This Been Tested?
Screenshots (if appropriate):
Types of changes
Checklist:
Summary by CodeRabbit
Security
Developer Experience
Compliance