[leomontigatti]

T3 update review: 0.1.5-nightly.20261029.3873 → 0.1.6-nightly.20261030.3917 (4 releases)

Needs you

• Quit T3 and open it from the desktop before you install the next update (shared,
  deb-update-relaunch-no-new-privs). The running app has NoNewPrivs: 1 (checked 2026-10-30 on
  3917), so its next "Restart to install" would fail with no password prompt. The fix,
  #15387, is still open.

Improves

No active entry broke and no watching entry became ready. These are evidence for the shared
t3-dependencies.md, written in this PR. No workflow needs to change.

• shared, storage-cleanup-removes-thread-worktrees: a provider session stop no longer starts
  a sweep unless a deleted thread's worktree is waiting
  (#26038, 3892). From the PR: "Only deletion
  cleanup is driven by events; the other worktree rules run on the hourly sweep." The keep reasons
  in Last run are unchanged. The entry named only the scheduled triggers, so it now records the
  event-driven ones too.
• shared, pr-linked-by-tool: the one-minute PR sweep now skips subagent and delegate
  children (#26983, 3892). A child's PR is
  looked up only after that child's own run, checkpoint, metadata update, unsettle or unarchive,
  so a PR that merges later doesn't update the child. Nothing here is affected: implement-spec
  children open no PR, and cleanup asks the host itself (gitManager.branchPullRequest in
  storageCleanup.ts).
• shared, delegate-task-worktrees: a held queue now releases messages from agents, the server
  and scheduled tasks once the thread's newest run completes
  (#27221, 3904). Before, they stayed held after
  a provider failure, restart or Stop, until a user message or queue.resume. Messages a user
  wrote still wait for that user. By that rule, a child's completion held on the parent now gets
  through; that reading comes from the PR and was not tried here.
• shared, delegate-task-reviews:
  • A restart continuation that fails before the provider took its prompt retries after 1 and
    3 minutes, and a child's continuation stands down when the parent's run was stopped
    (#27222, 3904).
  • Every Stop is now bounded at 15 s. Claude's and ACP's 10 s fallbacks no longer mark a turn
    stopped while the agent runs on, so an agent that ignores Stop shows "Agent not responding to
    Stop" until the user presses Force stop, which is not an MCP tool
    (#27252, 3917). task_cancel dispatches
    that same thread.stop. What task_status shows for such a child was not checked.
• shared, preview-tools-verification: the preview browser now runs in an agent scope, with
  the agents' +800 OOM score, low CPU weight and memory limits
  (#27239, 3904; the weights are
  #27176). From the PR: "under agent memory
  pressure the preview browser is throttled too." This may bear on the snapshot timeouts that block
  the trial, but nothing has tested that. Worth reading in the next preview run's notes.
• shared, deb-update-relaunch-no-new-privs: 3917 shows the flag still set after an in-app
  relaunch (the check under Needs you).

Drift

• rubens, no entry yet: docs/agents/validation.md § Why not pnpm test says "Agent threads
  on the machine share one memory limit". That is a T3 rule (agentSliceMemoryLimits in
  apps/server/src/process/agentScope.ts) that neither dependency file covers. It landed on
  2026-10-29. Measured here on a 14.8 GiB machine: MemoryHigh 8.8 GiB, MemoryMax 11.1 GiB on
  app-t3code-agents.slice.
  Proposed for rubens: an active entry agent-memory-limit, which says the limit is shared
  across threads and breaks if T3 changes the slice or its limits. When it lands, add that path to
  WATCHED_PATHS in changes.py. The other four projects' docs have no such rule.

Not covered

• infra: no docs/agents/t3-dependencies.md on origin/master or on any branch.

Still ready

• shared, preview-tools-verification: adoption step one has been under way since 2026-10-26.
  Step two (dropping the browser CLI) waits for ten PRs verified with preview_snapshot and no
  lost click.

Checked with no effect on us:

• t3 service protect (#27239): nothing to
  adopt. It targets the boot service, which isn't installed here (t3 service status: not
  installed), and the infra repo's README.md and AGENTS.md don't mention T3. This is read from
  the source; it was not run.
• #27176: app-t3code.slice now has
  CPUWeight=10, IOWeight=10 and TasksMax=25%, and the first two are confirmed live here.
  Agents give way only under contention.
• t3_thread_organize is now strict (#26718). No
  shared skill calls it.
• The scheduler's due hint in ScheduledTaskService.ts skips idle ticks. The missed-run and
  lastRunStatus logic is unchanged, and this run itself started on schedule.
• #25212 caps generated folder names at 40
  characters and keeps a hash, so rubens' and enescena's worktree-folder-names-unique still
  holds.
• ThreadLaunchService.ts is a read-path refactor. settings.ts adds secretProviders (behind
  T3CODE_FEATURE_SECRETS) and keeps unknown project overrides; en-escena's two settings are
  untouched. No other MCP tool or orchestratorMcp.ts shape changed, and the injected instructions
  are unchanged.
• background-service.md still says nothing about scheduled tasks, so en-escena's
  architecture-review-needs-app stands.
• #24097 applies only to a symlinked T3 home;
  ~/.t3 is a real directory here.

Other checks: the watched issues and PRs are unchanged. #17889, #17813, #22805, #11078, #14905,
#15387, #23936, #24812 and discussions 24108, 18047, 23245 and 23305 are all still open, and #5063
stays closed with the runner unchanged. #17889 has two new comments, and #14905 has one about an
Arch install, which is not our path. No fix merged. Every Used by file and heading exists, and
WATCHED_PATHS covers every cited T3 path. The only drift is the rubens rule above.

Projects whose behaviour changes: none. This PR only adds evidence to the shared t3-dependencies.md. The rubens entry stays a proposal, outside this diff.

Review

Tier: readback, reviewed 96757eb

• readback (Luna): no surprises

Readback

The commit adds evidence about T3 0.1.6 behaviour to t3-dependencies.md: thread and PR sweeps, child continuation and cancellation, queue release, the Linux update flag, and preview browser resource limits. The new notes mark several claims as unverified (task_status after a stop, whether queue release lets a child completion through, whether resource limits explain snapshot timeouts). Those caveats fit an evidence change; nothing else looks unrelated or contradictory. 0 surprises; Would merge: yes.

🤖 Generated with Claude Code