lean cloud push overwrites read-only shared library files

[AlexCatarino]

lean cloud push overwrites read-only shared library files

Summary

When a project references a shared library for which the pushing user has read-only (collaborator) access, lean cloud push still uploads the locally cached library files via /files/update, effectively overwriting whatever the library owner has since changed on the cloud. The access control on the library project is not consulted before the push.

Reproduction steps

1. Create a library project and share it across an organisation as read-only (i.e. other members are added as read-only collaborators, not owners).
2. A read-only collaborator runs lean cloud pull on a project that references this library → library files are downloaded locally.
3. The library owner pushes new changes to the library in the cloud.
4. The read-only collaborator runs lean cloud push on the project (not on the library directly).
5. Observed: the cloud library files are reverted to the version the read-only collaborator had locally from step 2.
6. Expected: lean cloud push should skip pushing files for libraries where the current user has read-only access (or the cloud API should reject the write with an appropriate error).

Root cause (hypothesis)

lean cloud push iterates over all local project files, including the contents of every linked library directory, and calls /files/update or /files/create for each. It does not check the authenticated user's role on the library project before pushing library files. The result is that a collaborator who cannot directly write to a library via the web IDE or via lean cloud push <library> can inadvertently overwrite it by pushing the parent project.

Suggested fix

Before pushing library files, retrieve the calling user's access level on each library project (e.g. via /projects/read for the library's project id and checking the collaborator role / access flag). Skip — or error — on any library where the user is not an owner or write collaborator.

A complementary server-side guard on /files/update to enforce the library project's collaborator permissions would provide defence-in-depth regardless of the client.

References

• Intercom conversation id: 215475353035232
• Related lean-cli open issue: Improve semantics of library organization #579 (Improve semantics of library organisation — may overlap)
• LEAN CLI docs: https://www.quantconnect.com/docs/v2/lean-cli/projects/libraries/project-libraries

[AlexCatarino]

Follow-up: write-collaborator escalation (2026-08-04)

A follow-up report on the same ticket has identified a related server-side side-effect.

When lean cloud push calls projects/update on a library project on behalf of a user who only has org-wide read-only access, the platform registers that user as an explicit write collaborator on the library project. This is visible in the library's Collaborators panel — the user appears as an individual write-access entry, separate from the org-wide read-only grant that was set originally.

Two observable effects from the same root cause:

1. The library's cloud files are silently overwritten (the original report above).
2. The pushing user is silently elevated to an explicit write collaborator on the library project.

Both effects stem from projects/update being accepted without enforcing the caller's access level on the library. The suggested fix (check caller's role before pushing library files + server-side guard on projects/update) would address both.

Workaround (shared with customer): after every lean cloud pull, delete the local library directory before running lean cloud push on the project. With no local library directory, the push cannot include library files and cannot trigger the collaborator escalation.

Intercom conversation id: 215475353035232