[codex] capture filetracking artifacts

[jdchawla29]

Summary

• capture changed deliverable artifacts from the workspace filetracking capability
• fold filetracking span emission into the eval observer and remove the separate telemetry helper
• collapse the environment-side filetracking service layer into file_tracker.py and trim pass-through helpers

Validation

• uv run --no-sync pytest hud/environment/tests/test_file_tracker.py hud/environment/tests/test_file_tracking.py hud/eval/tests/test_file_tracking_observer.py
• uv run --no-sync ruff check hud/environment/file_tracker.py hud/environment/tests/test_file_tracker.py hud/environment/tests/test_file_tracking.py hud/environment/workspace.py hud/eval/file_tracking.py hud/eval/tests/test_file_tracking_observer.py hud/settings.py
• uv run --no-sync pyright hud/environment/file_tracker.py hud/environment/tests/test_file_tracker.py hud/environment/tests/test_file_tracking.py hud/environment/workspace.py hud/eval/file_tracking.py hud/eval/tests/test_file_tracking_observer.py hud/settings.py

---

Note

Medium Risk
Teardown flush can emit large base64 artifact payloads in telemetry spans and over TCP; mitigations include capture caps and existing secret redaction, but payload size and observer refactor affect rollout observability paths.

Overview
Rollout file tracking now captures changed deliverables (PDF, Office, images, HTML, etc.) as base64 telemetry payloads, not only text diffs. FileTracker.flush_changes() returns a trailing diff plus a bounded capture block (extension filter, per-file and total caps, secret-shaped paths skipped). advance_baseline() also updates the artifact baseline so setup churn is excluded from final capture.

The filetracking/1 server gains a flush method; serve_file_tracking and the async handler move into file_tracker.py ( file_tracking.py removed). get_cumulative_diff is dropped in favor of flush-time diff + capture.

The eval file_tracking_observer still polls diff on an interval, but on teardown calls flush and emits filetracking.diff, filetracking.snapshot, and new filetracking.capture spans via inlined _emit_file_tracking ( hud/telemetry/filetracking.py removed). The client uses a 160 MiB read limit so large flush responses do not truncate.

^{Reviewed by Cursor Bugbot for commit 014529c. Bugbot is set up for automated code reviews on this repo. Configure here.}

[cursor]

Cursor Bugbot has reviewed your changes and found 2 potential issues.

^{❌ Bugbot Autofix is OFF. To automatically fix reported issues with cloud agents, enable autofix in the Cursor dashboard.}

Want reviews to match your repository better? Bugbot Learning can learn team-specific rules from PR activity. A team admin can enable Learning in the Cursor dashboard.

^{Reviewed by Cursor Bugbot for commit 6b6cd1d. Configure here.}

[chatgpt-codex-connector]

💡 Codex Review

Here are some automated review suggestions for this pull request.

Reviewed commit: 6b6cd1d048

ℹ️ About Codex in GitHub

Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you

• Open a pull request for review
• Mark a draft as ready
• Comment "@codex review".

If Codex has suggestions, it will comment; otherwise it will react with 👍.

Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".

[chatgpt-codex-connector]

💡 Codex Review

Here are some automated review suggestions for this pull request.

Reviewed commit: 014529c69d

ℹ️ About Codex in GitHub

Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you

• Open a pull request for review
• Mark a draft as ready
• Comment "@codex review".

If Codex has suggestions, it will comment; otherwise it will react with 👍.

Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".

[chatgpt-codex-connector]

Raise the frame cap for JSON-escaped diffs

Fresh evidence in the current revision is that the 160 MiB cap still assumes only about 2x JSON escaping, but the server writes frames with json.dumps(...).encode() using default ASCII escaping. When a near-50 MiB diff contains two-byte characters/emoji or control characters and flush also includes up to ~20 MiB of base64 artifacts, the serialized newline frame can exceed this limit even though the server-side diff and capture caps were respected; the client then rejects the response and teardown drops both the final diff and artifact capture.

Useful? React with 👍 / 👎.