Summary

Describe the problem and fix in 2–5 bullets:

• Problem: WS connect payload strings/collections had minimal bounds, allowing very large metadata in handshake frames.
• Why it matters: large connect metadata increases parser ambiguity and memory pressure before auth/session logic.
• What changed: tightened TypeBox schemas for request frame IDs/methods and connect metadata (max lengths, max items/properties) while preserving existing required fields and behavior.
• What did NOT change (scope boundary): auth logic, role/scope authorization flow, and non-connect method handling.

Change Type (select all)

• Bug fix
• Feature
• Refactor
• Docs
• Security hardening
• Chore/infra

Scope (select all touched areas)

• Gateway / orchestration
• Skills / tool execution
• Auth / tokens
• Memory / storage
• Integrations
• API / contracts
• UI / DX
• CI/CD / infra

Linked Issue/PR

• Closes #
• Related #

User-visible / Behavior Changes

Oversized handshake metadata and overlong request IDs/method names are now rejected during schema validation with the existing invalid-connect/invalid-request error path.

Security Impact (required)

• New permissions/capabilities? (No)
• Secrets/tokens handling changed? (No)
• New/changed network calls? (No)
• Command/tool execution surface changed? (No)
• Data access scope changed? (No)
• If any Yes, explain risk + mitigation:

Repro + Verification

Environment

• OS: macOS
• Runtime/container: Node 22 + pnpm
• Model/provider: N/A
• Integration/channel (if any): Gateway WS protocol
• Relevant config (redacted): default gateway config

Steps

1. Send WS connect with oversized client metadata or overlong request frame id.
2. Observe schema validation failure.
3. Send valid connect frame and verify success path unchanged.

Expected

• Invalid oversized metadata rejected early.
• Valid connect frames still accepted.

Actual

• Matches expected behavior.

Evidence

Attach at least one:

• Failing test/log before + passing after
• Trace/log snippets
• Screenshot/recording
• Perf numbers (if relevant)

Human Verification (required)

What you personally verified (not just CI), and how:

• Verified scenarios: protocol validator tests for unknown fields/max lengths and targeted gateway auth e2e invalid-connect case.
• Edge cases checked: unknown connect params field and unknown request-frame property still rejected; valid baseline connect still accepted.
• What you did not verify: full gateway e2e matrix beyond the targeted invalid-connect auth case.

Compatibility / Migration

• Backward compatible? (Mostly)
• Config/env changes? (No)
• Migration needed? (No)
• If yes, exact upgrade steps:

Failure Recovery (if this breaks)

• How to disable/revert this change quickly: revert this PR.
• Files/config to restore: src/gateway/protocol/schema/frames.ts.
• Known bad symptoms reviewers should watch for: legacy clients with unusually large connect metadata rejected at handshake.

Risks and Mitigations

• Risk: strict bounds may reject outlier client metadata values.
  • Mitigation: limits are set well above expected real values and validated by protocol tests + targeted e2e handshake test.

Greptile Summary

Tightens WebSocket connect frame validation by adding maximum length constraints to prevent oversized metadata in handshake frames. This reduces parser ambiguity and memory pressure before authentication logic executes.

• Adds sensible bounds for all connect metadata (256 char limit for most text fields, 8KB for paths/secrets, 16KB for signatures)
• Adds maxItems constraints to arrays (256 items max) and maxProperties to permissions (256 max)
• New test file validates bounds and ensures unknown fields are rejected via additionalProperties: false
• Existing valid connect flows remain unchanged (baseline compatibility maintained)

Confidence Score: 5/5

• Safe to merge - pure security hardening with comprehensive validation tests and no behavioral changes to valid clients
• All changes are additive security constraints that reject edge-case oversized payloads while preserving valid client behavior. New comprehensive tests validate both the rejection paths (oversized metadata, unknown fields) and acceptance paths (valid baseline connect). Limits are well above typical real-world values (256 chars for display names, 8KB for tokens, etc.)
• No files require special attention - both changed files are schema definitions with matching test coverage

_{Last reviewed commit: b4b1bef}