Verify sandbox.mcp.port validation already implemented

[Copilot]

Issue requested runtime validation for sandbox.mcp.port to enforce 1-65535 range constraints. Investigation revealed validation was already implemented in commit 57657bc (2026-01-29), after issue creation.

Current Implementation

Dual-layer validation:

• Schema validation in pkg/parser/schemas/main_workflow_schema.json enforces minimum: 1, maximum: 65535
• Runtime validation in pkg/workflow/sandbox_validation.go:157-162 uses validateIntRange helper
• Called during compilation at compiler.go:176

Test coverage:

• TestSandboxMCPGatewayPortValidation in sandbox_validation_test.go
• Edge cases: -1, 0, 1, 65535, 65536, 100000 all tested and passing

Validation Behavior

sandbox:
  mcp:
    port: 0      # ❌ Rejected: "minimum: got 0, want 1"
    port: -1     # ❌ Rejected: "minimum: got -1, want 1"  
    port: 65536  # ❌ Rejected: "maximum: got 65,536, want 65,535"
    port: 8080   # ✅ Compiles successfully

No code changes required. All success criteria from issue already met.

Original prompt

---

This section details on the original issue you should resolve

<issue_title>[Code Quality] Add runtime validation for sandbox.mcp.port constraints</issue_title>
<issue_description>### Description

The sandbox.mcp.port field has schema constraints (minimum: 1, maximum: 65535) but lacks runtime validation in the Go code. This allows invalid port numbers to pass through, potentially causing MCP gateway container startup failures and difficult-to-debug networking issues.

Priority: HIGH (issue has persisted for 15+ days according to audit)

Current Situation

Schema Definition:

{
  "port": {
    "type": "integer",
    "minimum": 1,
    "maximum": 65535,
    "description": "Port for the gateway HTTP server"
  }
}

Current Behavior:

• Schema declares valid port range: 1-65535
• Port is extracted in pkg/workflow/frontmatter_extraction_security.go:extractMCPGatewayConfig()
• NO validation is performed - invalid ports (0, -1, 99999) would pass through
• The validateIntRange helper exists but is not called for this field

Impact

• Security Risk: Port 0 could allow OS-assigned random ports
• Runtime Failures: Invalid ports cause container startup failures
• Debugging Difficulty: Errors manifest as networking issues rather than validation errors
• Schema Contract Violation: Runtime doesn't enforce what schema promises

Suggested Changes

Add validation call after port extraction in pkg/workflow/frontmatter_extraction_security.go:

// In extractMCPGatewayConfig after port extraction:
if mcpConfig.Port != 0 {
    if err := validateIntRange(mcpConfig.Port, 1, 65535, "sandbox.mcp.port"); err != nil {
        return nil, err
    }
}

Files Affected

• pkg/workflow/frontmatter_extraction_security.go (add validation call)
• pkg/parser/schemas/main_workflow_schema.json (schema already correct)

Success Criteria

• Port values outside 1-65535 range are rejected with clear error message
• Port value 0 is rejected (unless intentionally allowed)
• Validation uses existing validateIntRange helper for consistency
• Error message clearly states the valid port range
• Unit tests cover edge cases: 0, -1, 1, 65535, 65536, 99999

Source

Extracted from Schema Consistency Audit discussion githubnext/gh-aw#11412

Original Finding:

"Schema declares minimum: 1, maximum: 65535. NO validation called - invalid ports would pass through. First identified 2026-01-07, still not fixed as of 2026-01-22 (15 days)."

References:

• §21269056069

AI generated by Discussion Task Miner - Code Quality Improvement Agent

• expires on Feb 13, 2026, 1:34 AM UTC

Comments on the Issue (you are @copilot in this section)

• Fixes [Code Quality] Add runtime validation for sandbox.mcp.port constraints #12658

---

💡 You can make Copilot smarter by setting up custom instructions, customizing its development environment and configuring Model Context Protocol (MCP) servers. Learn more Copilot coding agent tips in the docs.