fix(sandbox-backend): raise control frame limit to 2 MiB

[benoitf]

Summary

Raise MAX_CONTROL_FRAME_BYTES from 1 MiB to 2 MiB so that hosts with large CA bundles (e.g. macOS default trust store ~334 KB, which inflates ~3.3× under serde's JSON byte-array encoding) no longer exceed the frame limit during StartAgent.

Related Issue

Closes #3453

Changes

• Increase MAX_CONTROL_FRAME_BYTES from 1024 * 1024 to 2 * 1024 * 1024 in openshell-sandbox-backend

Testing

• mise run pre-commit passes
• Unit tests added/updated
• E2E tests added/updated (if applicable)

Checklist

• Follows Conventional Commits
• Commits are signed off (DCO)
• Architecture docs updated (if applicable)

[copy-pr-bot]

This pull request requires additional validation before any workflows can run on NVIDIA's runners.

Pull request vetters can view their responsibilities here.

Contributors can view more details about this message here.

[elezar]

Does something like this validate adding a test case?

[elezar]

which inflates ~3.3× under serde's JSON byte-array encoding

Are there options to optimise this?

[benoitf]

which inflates ~3.3× under serde's JSON byte-array encoding

Are there options to optimise this?

@elezar it's related to ca_cert and ca_bundle

OpenShell/crates/openshell-sandbox-backend/src/boundary_protocol.rs

Lines 535 to 536 in 4b2cb7f

	ca_cert: Option<Vec<u8>>,
	ca_bundle: Option<Vec<u8>>,

ca_cert and ca_bundle in Request::StartAgent are Option<Vec> with no serde annotation. serde_json's default encodes each byte as a decimal integer in a JSON array ([45,66,69,71,...]), averaging ~3.3 bytes per input byte.
if for example encoding using base64 strings instead, reducing expansion from ~3.3x to ~1.33x.

[benoitf]

Does something like this validate adding a test case?

I've added a test

[elezar]

I see a co-authored-by attribution in the commit message.

@purp did you look at adding something that catches this?

[elezar]

@drew Could we address this at the type/serialization layer instead of increasing the global control-frame limit?

These values appear to be PEM text and must be supplied together, so would something like Option<CaMaterialWire>—containing ca_cert_pem: String and trust_bundle_pem: String—be a better representation than two independent Option<Vec<u8>> fields? That would encode close to the original PEM size in JSON and make the both-or-neither invariant explicit.

We would still need to handle wire compatibility deliberately, for example by accepting the legacy byte-array representation and negotiating when a sender may use the compact representation. Do you see the 2 MiB increase as a short-term compatibility measure, or should this PR address the representation itself?

[elezar]

Follow-up: these StartAgent fields were only introduced with the recent RFC 0012 implementation. If wire compatibility across these prerelease builds is not a supported contract, we can likely ignore legacy decoding and capability negotiation and change the representation directly. That would make the type-level fix considerably simpler.

[benoitf]

I see a co-authored-by attribution in the commit message.

@purp did you look at adding something that catches this?

edited

[benoitf]

I'm OK to do another proposal, as long as I'm able to start my sandbox

I pick-up the size increase first, as it was the thing not breaking protocol