[saphid]

Model: built with Claude Code; the exact Claude model was not recorded.

Head da57095d55 integrates main 44ecfd65b6. The conflict resolution retains main's known-workspace test service and symlink/Git-directory write protections, plus the short-read injection and regression tests. The production read loop remains the only behavior changed by this PR.

Problem

When the operating system returns fewer bytes than the server asked for, the Files panel opens only part of the file and says nothing. Such a short read is legal, for example on network or FUSE filesystems (SMB, NFS, sshfs) or while a file is being rewritten. The server made one read call and returned whatever came back with truncated: false. The result could be a prefix of a source file, a UTF-8 character cut in half, or a binary file shown as text because its NUL bytes came after the first chunk.

Because the result is not marked truncated, web and desktop open that prefix in the editable file surface with no "Preview limited" banner. Edits there are autosaved as the whole file, which overwrites everything after the prefix. The recordings below show a one-line edit deleting 97 lines of a source file on main.

Why this qualifies

This is a very small, focused fix for an obvious bug, which CONTRIBUTING allows without a prior issue. Node does not promise that one FileHandle.read fills the buffer, and the server already relies on it doing so. The fix finishes the bounded read the server already intends to do. It changes no contract, setting, read limit or product behavior. There is no linked issue or maintainer discussion, so the PR relies on the small-obvious-bug exception.

Change

WorkspaceFileSystem.readFile (apps/server/src/workspace/WorkspaceFileSystem.ts) now keeps reading at the current buffer and file offset until it has the bounded prefix (min(size, 1 MB)) or a read returns 0 bytes (EOF). It then runs binary detection and UTF-8 decoding on only the bytes that arrived. The error mapping is unchanged. byteLength and truncated still come from the initial stat. This does not give a consistent snapshot of a file that changes during the read.

Verification

Recovery verification on macOS (2026-10-17): vp test run apps/server/src/serverLogger.test.ts apps/server/src/workspace/WorkspaceFileSystem.test.ts apps/server/src/workspace/WorkspacePaths.test.ts passed all 45 tests. The logger and workspace-file suites passed all 37 tests with the fixes; restoring both production files to fetched main made four tests fail (two logger cause-rendering cases and both short-read cases), with 33 passing. Targeted vp lint, vp fmt --check, git diff --check, and the per-PR vp staged --diff BASE..TREE --no-stash --fail-on-changes hooks passed.

These checks used the existing dependency checkout at 70d60e03a7 with the candidate files and three required upstream files temporarily overlaid, while preserving an unrelated checkout overlay. They did not execute either complete candidate tree. The server typecheck failed with 106 error diagnostic lines; the same lines appeared with both production fixes restored to fetched main, including missing KnownWorkspaces wiring in the older checkout. No passing local full-candidate typecheck or build is claimed. GitHub CI on head da57095d55 has now passed all eight required checks, including Build and Typecheck and the server test shards. Source files and the real Git index were restored and verified afterward.

The recovery instruction explicitly forbids new delegates or threads, so there is no fresh independent review of this integration. The parent reviewed the complete two-file contributions; historical reviews below cover earlier revisions.

Historical Linux verification (earlier head 56a22d4371): 26 workspace-file/path tests passed, targeted lint and the server typecheck passed. A supplied server-process A/B with 2-byte native reads returned incomplete text and missed binary bytes on main; the fix returned complete text and rejected the binary file.

The client recordings and RPC reproduction below were made on the earlier head 1658d52, which has the same diff against main.

Environment: macOS 26.5.2 arm64, Node 24.12.0. Verified on upstream main 845ddd9354 with this branch rebased onto it.

In the web client. Each side ran vp run dev with fresh dev state. The before side was a checkout of main and the after side was this branch. Both used the short-read preload shown below, capping each native read to 4096 bytes. The client was the T3 web app in Chromium at 1440×900. The project was a disposable git repo holding one committed copy of apps/server/src/bootstrap.ts (6,786 bytes, 241 lines). On each side I opened the file in the Files panel, scrolled to the end, typed // edited in Files as a new first line, and waited for autosave. Then I ran wc -l -c bootstrap.ts; tail -n 3 bootstrap.ts; git diff --stat in the app's terminal. No provider turn was started.

• Before (main): the server made one read. The editor opened with no "Preview limited" banner and ended at line 145, partway through }).pipe(Effect.timeoutOption(timeoutMs), Effect.map(Option. After the autosave the file on disk was 4,115 bytes and ended at that same cut-off line. git diff --stat showed 2 insertions(+), 97 deletions(-): the rest of the file was gone.
• After (earlier capture head): the server finished the file in two reads (4,096 + 2,690 bytes). The editor showed all 241 lines, ending with return `/dev/fd/${fd}`; and }. After the autosave the file was 6,805 bytes and 242 lines, and git diff --stat showed 1 insertion(+).

Before (main): open, scroll to the end, edit, autosave, check the disk. The file ends at line 145 and the save deletes 97 lines.

After (earlier capture head): the same steps. The file ends at line 241 and the save adds only the edited line.

The GIFs play at 4× speed, sampled at 6 fps. Real-time recordings: before (main) MP4 (the first 20 s of startup are trimmed) and after (this head) MP4. The (eval) line in the terminal comes from the capture machine's shell startup and has nothing to do with this change.

Still screenshots

Before (main), end of the file in the editor: line 145, cut off mid-line.

Before (main), on disk after the autosave: 145 newlines, 4,115 bytes, 97 deletions.

After (earlier capture head), end of the file in the editor: line 241 is the closing brace.

After (earlier capture head), on disk after the autosave: 242 lines, 6,805 bytes, 1 insertion.

The top of the file on open, with no banner on either side: before, after. After the edit: before, after.

Historical real-server reproduction over the RPC. No SMB, NFS or FUSE mount was available, so I injected the short read at the native boundary. The real server ran with a node --import preload that caps every FileHandle.read on the fixture directory at 4096 bytes per call. Nothing else in the server changed. A client then called projects.readFile, the RPC that the web, desktop and mobile Files views use, on two fixtures:

• a copy of apps/server/src/ws.ts (164,336 bytes, 3,869 lines)
• a self-extracting installer: an 8,307-byte shell header followed by a gzip payload containing NUL bytes

The "before" run used the same checkout with main's WorkspaceFileSystem.ts restored, so it had no runtime difference from main.

Before (main):

projects.readFile ws.ts (on disk: 164336 bytes, 3869 lines)
  -> byteLength=164336 truncated=false returnedBytes=4096 returnedLines=118 exactMatch=false endsWith="tration-v2/ProviderSessionManager.ts\";\ni"
projects.readFile install.sh (text header + gzip payload with NUL bytes after byte 8307)
  -> SUCCESS (served as text) byteLength=12426 truncated=false returnedBytes=4096 containsNul=false

After (earlier capture head):

projects.readFile ws.ts (on disk: 164336 bytes, 3869 lines)
  -> byteLength=164336 truncated=false returnedBytes=164336 returnedLines=3869 exactMatch=true endsWith="e,\n        }),\n      ),\n    );\n  }),\n);\n"
projects.readFile install.sh (text header + gzip payload with NUL bytes after byte 8307)
  -> FAILURE ProjectReadFileError failure=binary_file

On main the server made one capped read per file and returned the first 4 KB as the complete file. That is 118 of 3,869 lines, stopping partway through an import line. The installer was served as editable text. With the fix the server read on through 41 capped reads for ws.ts, returned the exact file, and rejected the installer as binary.

Short-read preload used for the reproduction

import { createRequire, syncBuiltinESMExports } from "node:module";
const fsp = createRequire(import.meta.url)("node:fs/promises");
const nativeOpen = fsp.open;
fsp.open = async (path, ...rest) => {
  const handle = await nativeOpen(path, ...rest);
  if (String(path).startsWith(process.env.SHORT_READ_FIXTURE)) {
    const read = handle.read.bind(handle);
    Object.defineProperty(handle, "read", {
      value: (buffer, offset, length, position) => read(buffer, offset, Math.min(length, 4096), position),
    });
  }
  return handle;
};
syncBuiltinESMExports();

Regression tests, fail before / pass after. Two service tests use the real file reader, with each native read capped at 2 bytes:

• one checks that A café 🐈\n comes back whole
• one checks that ab\0cd is rejected as binary

Against main's unchanged WorkspaceFileSystem.ts, both fail with exit 1 (Tests 2 failed | 12 passed (14)): the text comes back as A , and the binary file returns ab. On that earlier revision, all 14 passed.

Historical commands on that earlier revision (TMPDIR=/private/tmp CI=true):

• vp run --filter t3 test src/workspace/WorkspaceFileSystem.test.ts: Tests 14 passed (14), exit 0.
• vp run --filter t3 typecheck: exit 0.
• vp lint on the two changed files: exit 0, no diagnostics.
• vp fmt --check on the two changed files: exit 0.
• git diff --check: exit 0.
• node scripts/release-smoke.ts: "Release smoke checks passed.", exit 0.

Surfaces

• Web: fixed. The Files panel gets the complete bounded text, or a binary error.
• Desktop: fixed, because it uses the same web UI and its bundled server gets this change.
• Mobile: fixed on the server side. The mobile file screens call the same projects.readFile RPC. I did not run the mobile app.
• Local / remote-relay / tunnel: not affected. The read runs on the server, and the RPC contract and payload shape are unchanged, so every transport gets the same result.
• Providers (Codex, Claude, Cursor, Grok, OpenCode, Antigravity): not affected. Workspace file reads do not go through a provider adapter.
• Contracts / docs: no change needed. The response shape and the 1 MB read limit stay the same.

Not checked

• A short read on a real network or FUSE mount. None was available, so the reproduction injects the short read in the real server process instead.
• A file rewritten during the read. The fix does not try to snapshot it.
• The desktop app, Windows, and the mobile app. The client check above used the web app on macOS; Linux coverage is the tests and server-process A/B listed under Verification.

GPT-6.1 Sol, Claude Opus 5.5 and GPT-6 Astra via T3 Code. Earlier merge with main: Claude Opus 5.5 (Claude Code) via T3 Code; historical validation GPT-6.1 Sol. Recovery integration and focused verification: GPT-6.1 Sol through Codex in T3 Code.
🤖 Generated with Claude Code

[macroscopeapp]

Approvability

Verdict: Approved at cb1a5f4

Macroscope's review found this PR approvable — This focused server fix completes bounded filesystem reads before decoding workspace text and adds regression tests for short UTF-8 reads and delayed binary bytes. It preserves the existing response contract and limits runtime impact to additional reads when the operating system returns partial results.

^{You can add or adjust custom eligibility rules. Learn more.}

Dismissing prior approval to re-evaluate a2a7b88

[coderabbitai]

No actionable comments were generated in the recent review.

Recent review info

Run configuration

• Source mode: Auto
• Repository: pingdotgg/t3code
• Branch: main
• File: .coderabbit.config.ts
• Commit: 961026c
• Layers: Repository TS config
• Review profile: CHILL
• Plan: Advanced
• Run ID: e328b1bd-9ed1-43ad-b3e6-3540e47e94df

Commits

Reviewing files that changed from the base of the PR and between cb1a5f4 and ff9a802.

Files selected for processing: 2

• apps/server/src/workspace/WorkspaceFileSystem.test.ts
• apps/server/src/workspace/WorkspaceFileSystem.ts

Limit details: You’ve used all 10 included reviews currently available.

Walkthrough

WorkspaceFileSystem.readFile now loops over short reads until it reaches the requested byte count or a read returns no bytes. Tests cover workspace-relative paths, UTF-8 decoding, byte length, truncation status, and binary-file detection.

Changes: Workspace file reads

Layer / File(s)	Summary
Read files across short reads apps/server/src/workspace/WorkspaceFileSystem.ts, apps/server/src/workspace/WorkspaceFileSystem.test.ts	readFile advances the file offset after each read and includes only bytes actually read. Tests simulate short reads and verify UTF-8 results and binary-file detection.

Estimated code review effort: 2 (Simple) | ~10 minutes

Change: Bug fix

Possibly related PRs

• pingdotgg/t3code#24255: Both changes affect readFile behavior before or during UTF-8 decoding.
• pingdotgg/t3code#20738: Conditional workspace writes use contents returned by readFile.
• pingdotgg/t3code#22339: Both changes concern incomplete reads and editing truncated Markdown previews.

Suggested reviewers: juliusmarminge

Merge Risk: Minimal · up to ff9a8

Short reads are completed before decoding. No actionable merge-blocking risk was identified.

Pre-merge checks: 4

Check name	Status	Explanation
Title check		The title clearly and concisely describes the main change: completing short reads before returning workspace text. It uses an appropriate conventional commit format.
Description check		The description is complete and follows the required template. It explains the problem, change, scope and approval rationale, focused verification, limitations, affected surfaces, and agent details. I…
Linked Issues check		Check skipped because no linked issues were found for this pull request.
Out of Scope Changes check		Check skipped because no linked issues were found for this pull request.

Full details: Description check

Explanation

The description is complete and follows the required template. It explains the problem, change, scope and approval rationale, focused verification, limitations, affected surfaces, and agent details. It also reports both successful checks and known test limitations.

Finishing Touches

Generate unit tests (beta)

• Create a new PR

• Autopilot · Keep fixing CodeRabbit findings and required CI, and resolving merge conflicts

Usage-based review receipt

• Mode: Continue automatically
• Reviewed files: 2
• Charged: $0.50
• View usage details

Note

This review was completed with usage-based billing: files reviewed beyond your plan's included limits are billed at $0.25/file. View usage-based billing.

[saphid]

Review requested

Date (UTC)	Reviewer	Where
2026-10-03	Julius	Discord DM

_{Logged so this PR shows when a maintainer was asked to review it.}

[saphid]

Review requested

Date (UTC)	Reviewer	Where
2026-10-06	Julius	Discord DM

_{Logged so this PR shows when a maintainer was asked to review it.}

Dismissing prior approval to re-evaluate cb1a5f4

[maria-rcks]

Note

Written by gpt-6.1-sol on behalf of Maria

Verified in a real dev environment

verified exact head ff9a802f6c33313c3b7356412866449d1a9339a3 against github/main 575579d68a on linux. each ran separately with vp i and a background dev server. used repo playwright and /usr/bin/google-chrome, added the real repository through the app, and completed real codex gpt-6.1-sol turns on both.

• opened the provider-generated /sys/kernel/btf/vmlinux link in Files. this authentic kernel file returns 4,096 bytes for a 1 miB request. syscall tracing showed main stops after that read; the pr advances offsets through 256 reads to complete the bounded 1 miB. no mocks, preloads or injected filesystem behavior. both clients correctly show no binary preview; the pr RPC returns binary_file.
• authenticated projects.readFile calls returned all 6,631 bytes of bootstrap.ts, exactly matching disk; a 1,408,141-byte markdown file returned the exact first 1,048,576 bytes with truncated: true; /sys/devices/system/cpu/online returned its four bytes and terminated at eof despite a 4,096-byte stat size. missing-file errors still return.
• edited the real README.md in Files. autosave preserved the entire original suffix. removed the edit through the same textbox and confirmed exact restoration on disk. final checkout is clean; no source changes or pushes.
• blacksmith ran the existing workspace file/path suites: 28 tests passed. latest github checks pass, with optional checks skipped.

command transcript and actual syscall excerpts

Not verified

natural short reads of utf-8 text or delayed nul bytes on network/fuse storage, and the destructive prefix-autosave reproduction. the live short-read comparison used a kernel binary, whose visible preview result is unchanged; utf-8 and delayed nul coverage comes from the existing tests. native desktop/mobile, macos/windows, and remote/relay/tunnel were not exercised on this linux vm. the historical state-directory diff in the recording is a verification artifact subsequently moved outside the repository. it is not a source change. uploaded video playback and seeking were checked in chrome.