You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
fix(server): an agent can no longer delete the project its own thread is in - #32748
t3_project_delete lets an agent delete the project its own thread is in. With force: true, the service deletes every thread in the project before the project itself. The calling thread is one of them, so its run ends in the middle of the tool call. The call never returns, and the agent never learns what it did. Any parent thread in the same project, such as the orchestrator that delegated the work, is deleted too.
I hit this for real. An agent capturing screenshots against its own dev server called t3_project_list and t3_project_delete, thinking they reached the dev server. They act on the T3 install the agent runs in, so it deleted that install's working project with force: true. Its own thread, its parent orchestrator and every other thread in the project (788 in total) went with it, and the tool call ended as interrupted.
Steps on main:
In a full-access thread, call t3_project_delete with this thread's projectId and force: true.
The project and all of its threads are deleted, this one included. The tool call never returns a result.
Change
The t3_project_delete handler now reads the caller from the access check it already runs. When the calling thread is in the target project, it refuses with invalid_request: "This thread is in that project, so deleting the project would delete this thread too." ProjectService is never called.
Nothing else changes. Clients with no calling thread, threads in other projects, the force rule and the service's cascade work as before. The Settings flow confirms the thread count before deleting; t3 project remove remains a user-run CLI command with its existing --force behavior, so both keep their behavior. The tool's description and schema are unchanged.
Scope and approval
This is a very small, focused fix of an obvious bug: an MCP tool call deletes its own caller and never returns. The check sits in the MCP handler, beside the existing caller access checks, because only an MCP call has a calling thread. ProjectService keeps its deletion behavior, as #10563 intended. It touches one handler and its existing test, with no contract or client change.
Verification
The existing t3_project_delete case in apps/server/src/mcp/toolkits/project/handlers.test.ts now makes three calls: a client delete (still deletes and discards the clone record), a live full-access thread in the target project (refused, nothing deleted), and a thread in another project (still deletes).
On main (vp test run apps/server/src/mcp/toolkits/project/handlers.test.ts):
FAIL src/mcp/toolkits/project/handlers.test.ts > an MCP project delete discards its clone record, unless the caller is in it
AssertionError: expected { id: 'project:client-target', …(12) } to match object { code: 'invalid_request', …(1) }
Tests 1 failed | 12 passed (13)
With this change: Tests 13 passed (13). vp run check:changed 836b86a5d6b7738193656b9c638318afe6caef35 passes (format, lint, knip 1/2, knip 2/2, GraphQL, typecheck for 3 packages, and tests for 2 files; exit 0).
For the screenshots, a scripted ACP agent runs as the provider of an isolated dev server. It calls the real t3_project_delete tool with its own thread's project, in a test project with two other threads.
The test project with two threads, before the agent's thread starts:
Before, on main (836b86a5d6): the call never returns, and the project and all of its threads are gone, the agent's own thread included.
After (ab707df885): the call is refused, and the project and all three threads stay.
Not checked: desktop and mobile render the same server result and were not run separately. A thread can still delete another project that holds its parent thread; this change covers only the caller's own project.
Generated with Claude Opus 5.5 and GPT-6.1 Terra and GPT-6.1 Sol in T3 Code Nightly
… is in
t3_project_delete let a thread delete the project it runs in. With force: true
the cascade deletes every thread in the project, the caller included, while the
call is still running, so the tool never returns and the agent never learns
what it did.
The MCP handler now refuses that call with invalid_request when the calling
thread's project is the target. Client callers, other projects, the force rule
and the service cascade are unchanged.
Macroscope's review found this PR approvable — The handler now prevents an agent from deleting the project containing its own thread. This narrowly scoped safeguard runs before deletion and preserves existing access checks and other deletion behavior.
You can add or adjust custom eligibility rules. Learn more.
No actionable comments were generated in the recent review.
Walkthrough
The MCP project-delete handler rejects deletion when the caller’s thread belongs to the target project. Tests cover this rejection and verify clone-record discard behavior for callers without a thread and callers whose thread belongs to another project.
The handler returns invalid_request when the caller’s project matches the deletion target. Tests cover this rejection and verify clone-record discard behavior for permitted deletions.
pingdotgg/t3code#24915: Adds the project-delete clone-record discard behavior that this PR’s tests verify for permitted deletions.
Suggested labels:bugfix
Suggested reviewers:dw3105
Merge Risk: Minimal · up to ab707
This change stops an agent from deleting the project its own thread is in. Other callers and the Settings flow are unaffected, and no merge-blocking risk was found.
Pre-merge checks: 4
Check name
Status
Explanation
Title check
The title clearly and concisely describes the primary change: preventing an agent from deleting the project that contains its own thread.
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.
Description check
The description follows the repository template and covers the problem, change, scope, and verification. The Problem section gives reproduction steps and the observed failure. The Change section state…
Full details: Description check
Explanation
The description follows the repository template and covers the problem, change, scope, and verification. The Problem section gives reproduction steps and the observed failure. The Change section states the new invalid_request refusal and what stays unchanged. The Scope section argues the fix qualifies as a very small, focused fix of an obvious bug and links the related issue #10563. The Verification section lists the test run, the before and after results, the check command with its outcome, and the screenshots. It also states what was not checked. The description does not cite a maintainer approval comment, and the Scope section reasons from the author's view rather than linking one. The reviewer may want to confirm that the fix qualifies for the no-prior-issue exemption. The description also names the model and harness used, which the template asks for.
Finishing Touches
Generate unit tests (beta)
Create a new PR
Autofix · Keep fixing CodeRabbit findings and required CI, and resolving merge conflicts
Included review availability: This review used your included allowance. Your plan provides up to 10 included reviews per hour; 3 remain after this review.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
size:XS0-9 changed lines (additions + deletions).vouch:unvouchedPR author is not yet trusted in the VOUCHED list.
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
github-actions
Bot
added
vouch:unvouched
![macroscopeapp[bot]](https://avatars.githubusercontent.com/in/900172?s=60&v=4){kind=small}
Problem
t3_project_deletelets an agent delete the project its own thread is in. Withforce: true, the service deletes every thread in the project before the project itself. The calling thread is one of them, so its run ends in the middle of the tool call. The call never returns, and the agent never learns what it did. Any parent thread in the same project, such as the orchestrator that delegated the work, is deleted too.I hit this for real. An agent capturing screenshots against its own dev server called
t3_project_listandt3_project_delete, thinking they reached the dev server. They act on the T3 install the agent runs in, so it deleted that install's working project withforce: true. Its own thread, its parent orchestrator and every other thread in the project (788 in total) went with it, and the tool call ended as interrupted.Steps on
main:t3_project_deletewith this thread'sprojectIdandforce: true.Change
The
t3_project_deletehandler now reads the caller from the access check it already runs. When the calling thread is in the target project, it refuses withinvalid_request: "This thread is in that project, so deleting the project would delete this thread too."ProjectServiceis never called.Nothing else changes. Clients with no calling thread, threads in other projects, the
forcerule and the service's cascade work as before. The Settings flow confirms the thread count before deleting;t3 project removeremains a user-run CLI command with its existing--forcebehavior, so both keep their behavior. The tool's description and schema are unchanged.Scope and approval
This is a very small, focused fix of an obvious bug: an MCP tool call deletes its own caller and never returns. The check sits in the MCP handler, beside the existing caller access checks, because only an MCP call has a calling thread.
ProjectServicekeeps its deletion behavior, as #10563 intended. It touches one handler and its existing test, with no contract or client change.Verification
The existing
t3_project_deletecase inapps/server/src/mcp/toolkits/project/handlers.test.tsnow makes three calls: a client delete (still deletes and discards the clone record), a live full-access thread in the target project (refused, nothing deleted), and a thread in another project (still deletes).On
main(vp test run apps/server/src/mcp/toolkits/project/handlers.test.ts):With this change:
Tests 13 passed (13).vp run check:changed 836b86a5d6b7738193656b9c638318afe6caef35passes (format, lint, knip 1/2, knip 2/2, GraphQL, typecheck for 3 packages, and tests for 2 files; exit 0).For the screenshots, a scripted ACP agent runs as the provider of an isolated dev server. It calls the real
t3_project_deletetool with its own thread's project, in a test project with two other threads.The test project with two threads, before the agent's thread starts:
Before, on
main(836b86a5d6): the call never returns, and the project and all of its threads are gone, the agent's own thread included.After (
ab707df885): the call is refused, and the project and all three threads stay.Not checked: desktop and mobile render the same server result and were not run separately. A thread can still delete another project that holds its parent thread; this change covers only the caller's own project.
Generated with Claude Opus 5.5 and GPT-6.1 Terra and GPT-6.1 Sol in T3 Code Nightly