Delete files from the server
ptero_delete_filePermanently delete files or directories on a Pterodactyl server with two-phase confirmation, automatic backup, and protection for critical paths. Requires explicit approval to prevent irreversible data loss.
Instructions
Permanently delete one or more files or directories. THIS IS IRREVERSIBLE WITHOUT A BACKUP — the panel has no trash and no undo. Deleting a directory deletes everything under it. Prefer ptero_rename_file (rename it out of the way) whenever the change might need undoing.
Every guardrail applies:
Deletion is OFF unless the operator set PTERODACTYL_ALLOW_DELETE=true; otherwise every call is refused.
Paths matching PTERODACTYL_PROTECTED_PATHS are refused — by default the world directories, server.properties, ops.json, whitelist.json and banned-*.json.
More than 10 files in one call is refused; narrow the list and work in batches.
An automatic backup is taken before the delete, and the operation is aborted if the backup fails.
The first call does NOT delete anything. It returns status "needs_confirmation" with a preview listing the root, the exact files and the count, plus a single-use token that expires in 120 seconds. THAT PREVIEW IS FOR THE HUMAN: put it in your reply, let them read the list, and only call again with the confirmation_token once they have said yes. Do not round-trip the token automatically — the whole point is that a person sees what is about to be destroyed.
Use dry_run=true if you only want to check what a delete would resolve to.
Input Schema
| Name | Required | Description | Default |
|---|---|---|---|
| root | No | Directory the entries in `files` live in, relative to the server root. Defaults to `/`. E.g. `plugins` when deleting `foo.jar`. | / |
| files | Yes | Names to delete, relative to `root` — bare names such as `foo.jar`, not full paths. Maximum 10 per call. Directories are deleted with all their contents. | |
| server | No | Server short identifier (e.g. 1a2b3c4d). Omit to use PTERODACTYL_DEFAULT_SERVER. Call ptero_list_servers to discover valid identifiers. | |
| dry_run | No | When true, validate and preview the change without performing it. Nothing is modified and no confirmation token is issued. Use this to reason about an operation before committing to it. | |
| confirmation_token | No | Two-phase confirmation token. Leave this out on the first call: the tool will refuse to act and instead return a preview of exactly what would change, plus a single-use token that expires in 120 seconds. THE PREVIEW IS FOR THE HUMAN — show it to the user in your reply and let them decide. Do not silently round-trip the token back in an immediate second call. Only call again with the token once the user has seen the preview and approved it. The token is bound to a hash of these exact arguments, so changing any argument invalidates it. |
Output Schema
| Name | Required | Description | Default |
|---|---|---|---|
| root | No | ||
| files | No | Names deleted, relative to `root`. | |
| reason | No | Why the call was refused. | |
| server | Yes | ||
| status | Yes | success = the change was made. refused = a guardrail blocked it (see reason/variable). dry_run = nothing changed; preview shows what would. needs_confirmation = nothing changed; SHOW the preview to the human and, only if they agree, call again with confirmation_token. | |
| message | No | ||
| preview | No | What would / did change. | |
| variable | No | Environment variable that caused the refusal. | |
| backup_id | No | UUID of the automatic pre-change backup, if one was taken. | |
| expires_in_s | No | ||
| confirmed_via | No | ||
| deleted_count | No | ||
| confirmation_token | No |