Check-out & check-in

Checking out a prop gives you an exclusive lock on it. While you hold the lock, nobody else can publish a new version of that prop or restore an earlier one, so you can edit without someone else’s change landing on top of yours. When you’re done, you check in your edited file as a new version, and release the lock.

What a lock does

One person holds a prop’s lock at a time. The lock covers the prop’s whole version history, including any labeled variants in it.
While someone else holds the lock, your push of a new version of that prop is held back and reported as locked. Other items in the same push still go through.
While someone else holds the lock, you also can’t restore an earlier version or otherwise change which version is current. The attempt fails with a message that the prop is checked out by another user (agents and the REST API get LOCKED naming the holder). Admins are the exception: they can restore a version on a locked prop.
A lock does not block downloads, pulls, comments or reviews.
Locks need a connection. You can’t take or release a lock while offline, because a lock granted offline would not be a lock.

Who can take and release a lock

Any member can check out a prop that nobody holds. Only the holder can release it, except that admins can force release anyone’s lock. Checking out a prop you already hold simply refreshes its expiry.

Expiry

A lock lasts 72 hours by default and then lapses on its own, so an abandoned check-out never blocks a prop forever. Agents and the REST API can choose a lifetime from 1 hour to 30 days (ttl_hours, 1 to 720). To extend your lock, check the prop out again before it lapses.

When a lock lapses, the prop is free again. The web library shows Lock expired — previously held by <name> in the check-out button’s tooltip, and the desktop app’s Checkouts page shows Checked out · lock lost or expired for your copy.

Check out

On a prop’s page, the lock button sits in the header next to the watch bell and Download.

When the prop is free, the button is labeled Check out (tooltip: “Check out — lock this asset for editing”). Select it to take the lock.
When you hold the lock, the button reads Release lock, and its tooltip shows Checked out by you · until <date>.
When someone else holds it, the button is disabled and its tooltip names them: Checked out by <name> · until <date>, followed by their note if they left one.

Checking out in the browser only takes the lock. Use Download to get the file.

In the desktop app you can also check out from the Local Library: Check out takes the lock, downloads the current version, and takes you to the Checkouts page.

Call checkout_prop with an entry_id (or lineage_id). You can add a note, which is shown to teammates who are blocked, and a ttl_hours. The result includes the lock, the current version’s object_id and content hash, and a download URL. The lock records that version as base_object_id, the version you started from.

If someone else holds the lock, the call fails with LOCKED and names the holder. Coordinate with them rather than working around it. list_checkouts shows who has what checked out.

Check in

Checking in publishes your edited file as a new version of the prop. It uses the same push as any other publish, so the new version becomes the current version and the prop’s review state resets to Draft.

Open Checkouts (under This Machine). Each row shows the asset, its state, the version you started from and your local file, and the lock.
Edit the file. After the next disk scan, the row’s state changes from Unchanged to Edited.
Optionally tick Release my lock after check-in.
Select Check in. The state shows Checking in… while the upload runs, and links to the upload on the Transfers page.

If you ticked the release option, your lock is released once the new version is committed. A row marked Conflict must be resolved first (see Conflicts).

Call checkin_prop with the prop’s entry_id, the new file’s SHA-256 as content_hash, and blob_size. Small files can ride inline as file_base64; for larger files the first call returns upload_required with upload instructions, and you call checkin_prop again after uploading. Pass release_lock: true to release your lock after a successful check-in.

The outcome is checked_in (a new version is live) or no_change (the bytes match an existing version). See the tool reference for the full set of outcomes.

If the prop changed while you were editing

Prophouse remembers which version you started from. If a different version became current in the meantime (for example, because your lock lapsed and someone else published, or an admin restored another version), your check-in is refused instead of silently replacing their work.

In the desktop app, the file appears on the Conflicts page, showing your file and the version the server moved to. Choose Keep my version to check yours in as a new version, or Take server version to replace your local file with the server’s. Nothing is lost either way.
Agents get a STALE_FACE error. checkin_prop compares against the version recorded on the agent’s lock when it checked out, even if the agent doesn’t pass expected_face_object_id. Release the checkout, check out again to get the current version, and redo the edit before checking in.

Release without checking in

To abandon an edit and free the prop:

Web and desktop: select Release lock in the prop header, or on the Checkouts page.
Unreal: right-click the tile and choose Release lock.
Agents: call release_checkout with the lock_id, or with the entry_id to release your own lock on that prop.

Force release (admins)

Admins can release someone else’s lock, for example when a teammate is away and a prop is blocked. On the prop page the lock button reads Force release for admins. On the desktop Checkouts page, Force release asks for confirmation first, because the holder may lose unsaved work. The holder keeps their local file; they just no longer hold the lock.