Repository navigation
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Harden sandbox.mcp.env key encoding at emission and launch boundaries #53171
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Uh oh!
There was an error while loading. Please reload this page.
Harden sandbox.mcp.env key encoding at emission and launch boundaries #53171
Changes from 2 commits
b8c358e935197e893826f29b8ce890196728ac725613106bbFile filter
Filter by extension
Conversations
Uh oh!
There was an error while loading. Please reload this page.
Jump to
Uh oh!
There was an error while loading. Please reload this page.
There are no files selected for viewing
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
[/tdd] Test uses hardcoded string literals (
"GH_AW_MCP_GATEWAY_ENV_0","GH_AW_MCP_GATEWAY_CUSTOM_ENV_NAMES") rather than the module constants. If either constant value changes, this test will silently pass while the behaviour diverges.💡 Suggestion
Export the constants from
start_mcp_gateway.cjsand import them in the test:The Go contract test already verifies constant values end-to-end, so this change would make the JS test self-consistent with the same discipline.
@copilot please address this.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
[/tdd]
TestMCPGatewayCustomEnvMarkerOmittedWhenAllNamesFilteredverifies that the container command string is empty when all names are invalid. However the assertionassert.Empty(t, containerCommand.String())checks the entire container command output — ifappendMCPGatewayCustomAndHTTPEnvFlagsever emits non-custom content before or after the marker check (e.g. HTTP MCP env flags added to the same builder), the test could mask a regression where the marker is still written.💡 Suggestion
Assert specifically that the marker constant is absent rather than that the whole output is empty:
This makes the assertion more intent-revealing and resilient to future additions.
@copilot please address this.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
L93-96: yagni: builds a
map[string]struct{}+setutil.Containsjust to test membership in a small slice already in scope.slices.Contains(customEnvVarNames, envVarName)(package already imported), 0 extra lines.There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
[/diagnosing-bugs]
sanitizedGatewayEnvNamesis called twice for every gateway config that has env vars: once here to decide whether to write the marker, and once insidewriteMCPGatewayStepEnv(indirectly throughappendMCPGatewayCustomAndHTTPEnvFlags→writeMCPGatewayStepEnv). The double-call is cheap now but creates a subtle maintenance trap — a future caller that mutates the map between calls could produce a marker with no corresponding env vars (or vice-versa).💡 Suggestion
Consider caching the sanitized slice on
MCPGatewayRuntimeConfig(or threading it as a parameter) so the guard and the emission path share a single computation:This also makes it easier to write a test that asserts marker presence ↔ non-empty sanitized names in one place.
@copilot please address this.
Uh oh!
There was an error while loading. Please reload this page.