Navigate logical layers of code changes, visualize relationships, and explore their blast radius.
🧰 Additional context used
📚 Code guidelines (2)
| 1 | docs/internals/effect-services.md — auto-discovered |
| 2 | AGENTS.md — auto-discovered |
📝 Walkthrough
Walkthrough
The pull request raises the generic attachment size ceiling to 100,000,000 bytes, updates client-side limit messages and documentation, and adds boundary and large-upload coverage. It also changes preview-recording limit text to 100 MB while keeping Antigravity’s total attachment budget at 50 MiB.
Changes
Attachment size limit
| Layer / File(s) | Summary |
|---|---|
Attachment contract and upload coverage packages/contracts/src/chatAttachment.ts, packages/contracts/src/assets.test.ts, apps/server/src/environment/ServerEnvironment.test.ts, apps/server/src/assets/AttachmentUpload.test.ts | The generic attachment ceiling and server capability use 100,000,000 bytes. Tests cover the boundary and a streamed 100 MB upload, including cleanup. |
Client limits and messages apps/mobile/src/lib/composerFiles.test.ts, apps/mobile/src/features/sharing/incoming-share-model.test.ts, packages/client-runtime/src/state/attachments.ts, packages/client-runtime/src/state/attachments.test.ts, docs/user/composer.md | Client tests and documentation use the 100 MB ceiling. Exact decimal-million-byte limits display in decimal MB. |
Provider processing and preview limits apps/server/src/orchestration-v2/AttachmentPrompt.test.ts, apps/server/src/provider/opencodeRuntime.cliParsers.test.ts, apps/server/src/provider/acp/AntigravityAcpSupport.ts, apps/server/src/mcp/toolkits/preview/tools.ts, packages/contracts/src/previewAutomation.ts | Tests cover 100 MB attachments in prompt and provider paths. Antigravity’s total attachment budget remains 50 MiB. Preview recording limit text changes to 100 MB. |
Priority: ➖ Normal
Estimated code review effort: 2 (Simple) | ~10 minutes
Change: Feature
Possibly related PRs
- pingdotgg/t3code#13261: It also raises the ordinary file-attachment limit to 100,000,000 bytes and preserves Antigravity’s separate 50 MiB budget.
Suggested reviewers: juliusmarminge, t3dotgg
Merge Risk: 🟡 Moderate · up to cbcfa
Older installed clients may fail to open messages containing newly accepted attachments. Confirm compatible-reader rollout or explicitly accept that risk before merging.
Security Architecture Review
Security architecture risk: 🟡 Moderate · up to cbcfa
The larger limit preserves per-upload byte checks and native-media budgets. However, compatibility updates must precede acceptance of larger files, and each valid upload can consume about 1.91 times the previous storage and bandwidth. Release readiness and aggregate resource limits remain unverified.
Retained concerns
- Medium · architecture · inferred: Acceptance of files above the former 50 MiB ceiling can create persisted message metadata that pre-update clients or a rolled-back reader reject, impairing thread access and rollback. The PR acknowledges this dependency, but prerequisite compatible-reader deployment is unverified; this is a conditional compatibility concern, not an observed production failure.
- Low · security · inferred: The increased ceiling raises storage and transfer allowance per valid upload attempt by about 1.91 times. The inspected persistence path permits repeated token use and independent concurrent temporary files, while aggregate resource controls are unverified. Replay semantics are pre-existing; the changed allowance increases their resource cost without establishing a denial-of-service vulnerability.
Security review details
Security Blast Radius
- inferred — The directly increased exposure is transfer bandwidth and attachment storage on the receiving server, including pending files, concurrent temporary files, and thread-owned copies. File contents can subsequently be inspected through existing agent-readable paths. Tenant isolation and deployment-wide capacity were not established.
Security Findings and Attack Paths
- inferred — A holder of a valid upload token can submit repeated or concurrent claim-sized bodies during its validity period in the inspected path. The higher ceiling increases resource cost per attempt. Token acquisition authority and external resource controls remain unresolved, so this is a conditional resource-pressure path rather than a verified arbitrary unauthenticated upload or denial-of-service finding.
Trust Boundaries and Controls
- observed — Upload ingress requires a valid signature and unexpired upload claim, binds received bytes to the signed size, and resolves storage paths beneath the attachment root. Preview stop requires the preview capability and claims the artifact using the invocation thread identity. These inspected controls remain relevant to the larger accepted payloads.
Resilience and Maintainability Implications
- observed — Upload persistence finalizes only after exact byte validation and attempts temporary-file removal in a finalizer. Pending deletion refuses thread-owned IDs, and issuance periodically triggers a stale pending/partial-file sweep. The sweep is issuance-triggered, not evidence of an independent cleanup service; all abandonment and recovery callers were not verified.
Hardening Proposals
- proposed — Gate larger-file acceptance on confirmed compatible-reader distribution, and keep rollback readers capable of consuming already-created larger attachment metadata. Separately establish an aggregate upload and storage budget that includes concurrent temporary files and pending-to-thread copies.
🚥 Pre-merge checks | ✅ 5
✅ Passed checks (5 passed)
| Check name | Status | Explanation |
|---|---|---|
| Title check | ✅ Passed | The title clearly summarizes the main change: raising the file upload limit to 100 MB while preserving native media limits. |
| Description check | ✅ Passed | The description covers the problem, changes, scope and approval context, verification results, and the outstanding reader-rollout dependency. It uses different headings from the template, but includes… |
| Docstring Coverage | ✅ Passed | Docstring coverage is 100.00% which is sufficient. The required threshold is 80.00%. Docstring coverage is scoped to functions touched by this diff. Analyzed 1 functions across 13 files. (1 skipped: 1… |
| Linked Issues check | ✅ Passed | Check skipped because no linked issues were found for this pull request. |
| Out of Scope Changes check | ✅ Passed | Check skipped because no linked issues were found for this pull request. |
✨ Finishing Touches
🧪 Generate unit tests (beta)
- Create a new PR
- Autopilot · Keep fixing CodeRabbit findings and required CI, and resolving merge conflicts
Comment @coderabbitai help to get the list of available commands.
