Project Save As
Policy authors: project grants follow the GUID, not the file. A WRITE grant for Original.prproj@GUID can therefore authorize editing or closing its Save-As copy at another path. Configure filesystem.writeAllow (fsWriteAllow internally) as well to restrict the actual save paths checked by saveProject and saveProjectAs; this is not a path restriction on all editing or Close operations. The same behavior is inferred, not live-tested, for an Explorer/Finder copy retaining the GUID when only that copy is open. For identity-qualified project allowlists, use Name.prproj@GUID (for example Copy.prproj@22222222-2222-2222-2222-222222222222). Bare GUIDs and prbind_... tokens are accepted as project parameters, not as project allowlist entries; there they are interpreted as relative item paths. A binding token is not itself a permission grant. This is Save As, not an export-only backup: Adobe documents that the native Project object represents the saved copy afterwards. Do not assume subsequent operations still target the original project. Treat pre-save concrete refs and run-scoped bindings as potentially stale after Save As. Current bindings are tied to the registered path/name/GUID and do not automatically migrate to a new saved identity. Rediscover the intended project and its refs before continuing; do not silently substitute the active project if a binding stops resolving. Live-verified on Windows Premiere Beta 27.0: Save As changed the retained Project object's name/path to the copy while preserving its GUID. The pre-save binding became stale under all tested grants, including "*"; the old bare GUID resolved the copy while unique among open resources. This is not a cross-version guarantee or a tested replacement-binding handoff. Rediscover and verify the intended resource after saving. The block returns only its existing success result, not a new GUID or binding. A Name.prproj@GUID allowlist is GUID-oriented, not pinned to that filename/path: when the GUID identifies one open resource, the readable name is diagnostic and may be stale. Both Original and Copy name prefixes with the same unique GUID authorized the observed resource before and after Save As. The name becomes a discriminator when multiple open resources share the GUID; a bare colliding GUID fails closed. Bare storeBindingIn tokens and bare project GUIDs are absolute project identities, not active-relative targets. Restricted Premiere permissions resolve them to the exact project identity before allowlist comparison; invalid or expired bindings fail with STALE_PROJECT_BINDING, including with "*" (then validated by the host). For bare identity targets, relative allowlist entries retain the project context captured at run start: rights for the original project do not authorize a newly created project. Active-relative targets such as ::SEQ\ACTIVE or \Bin still fail after an active-project identity change; they are not redirected to the original project. Existing explicitly project-qualified target refs retain their target-prefix qualification of relative allowlist entries. Evidence: [Adobe 26.5 changelog](https://developer.adobe.com/premiere-pro/uxp/changelog/), plus the Adobe sample panel's import.ts and project.ts. If project is omitted, the current Premiere project is used when supported. Use onError to decide whether errors stop the script, continue, or return false when the block supports it. If storeResultIn is set, the block also writes a result variable back to your graph.
Inputs
| Input | Required | Value Kind | Types | Enum Values |
|---|---|---|---|---|
path | yes | expression | file-path-string | — |
project | no | expression | reference, string, null | — |
onError | no | expression | enum-string | STOP, CONTINUE, RETURN_FALSE |
storeResultIn | no | variable-name | variable-name | — |
Notes
- Policy authors: project grants follow the GUID, not the file. A WRITE grant for
Original.prproj@GUIDcan therefore authorize editing or closing its Save-As copy at another path. Configurefilesystem.writeAllow(fsWriteAllowinternally) as well to restrict the actual save paths checked bysaveProjectandsaveProjectAs; this is not a path restriction on all editing or Close operations. The same behavior is inferred, not live-tested, for an Explorer/Finder copy retaining the GUID when only that copy is open. - For identity-qualified project allowlists, use
Name.prproj@GUID(for exampleCopy.prproj@22222222-2222-2222-2222-222222222222). Bare GUIDs andprbind_...tokens are accepted as project parameters, not as project allowlist entries; there they are interpreted as relative item paths. A binding token is not itself a permission grant. - This is Save As, not an export-only backup: Adobe documents that the native Project object represents the saved copy afterwards. Do not assume subsequent operations still target the original project.
- Treat pre-save concrete refs and run-scoped bindings as potentially stale after Save As. Current bindings are tied to the registered path/name/GUID and do not automatically migrate to a new saved identity. Rediscover the intended project and its refs before continuing; do not silently substitute the active project if a binding stops resolving.
- Live-verified on Windows Premiere Beta 27.0: Save As changed the retained Project object's name/path to the copy while preserving its GUID. The pre-save binding became stale under all tested grants, including
"*"; the old bare GUID resolved the copy while unique among open resources. This is not a cross-version guarantee or a tested replacement-binding handoff. Rediscover and verify the intended resource after saving. The block returns only its existing success result, not a new GUID or binding. - A
Name.prproj@GUIDallowlist is GUID-oriented, not pinned to that filename/path: when the GUID identifies one open resource, the readable name is diagnostic and may be stale. Both Original and Copy name prefixes with the same unique GUID authorized the observed resource before and after Save As. The name becomes a discriminator when multiple open resources share the GUID; a bare colliding GUID fails closed. - Bare
storeBindingIntokens and bare project GUIDs are absolute project identities, not active-relative targets. Restricted Premiere permissions resolve them to the exact project identity before allowlist comparison; invalid or expired bindings fail withSTALE_PROJECT_BINDING, including with"*"(then validated by the host). For bare identity targets, relative allowlist entries retain the project context captured at run start: rights for the original project do not authorize a newly created project. Active-relative targets such as::SEQ\ACTIVEor\Binstill fail after an active-project identity change; they are not redirected to the original project. Existing explicitly project-qualified target refs retain their target-prefix qualification of relative allowlist entries. - Evidence: Adobe 26.5 changelog, plus the Adobe sample panel's
import.tsandproject.ts.
See Also
- Premiere Reference Paths: Explains Premiere reference path strings for project items, sequences, tracks, timeline items, markers, components, and parameters.