Request for OPTIONAL READ-ONLY personal-files (read-only) for pieces-os

name: pieces-os

description: PiecesOS is a local-first workflow memory engine that automatically captures, structures, and resurfaces the context of your work across your entire toolchain.

upstream: https://pieces.app

upstream-relation: official package

interfaces:

  • browser-history-chrome:

    • request-type: manual-connection

    • reasoning: We’re building an agentic search engine for desktops to search memories that are formed on behalf of the user. We need this permission for read-only access to Chrome’s history SQLite databases to index and resurface user browser history. Under strict confinement, the home interface does not permit access to hidden directories (e.g., ~/.config/). Without this, the app encounters sqlite 14 (Permission denied) errors.

  • browser-history-chromium:

    • request-type: manual-connection

    • reasoning: Same as above for Chromium.

  • browser-history-brave:

    • request-type: manual-connection

    • reasoning: Same as above for Brave.

  • browser-history-edge:

    • request-type: manual-connection

    • reasoning: Same as above for Microsoft Edge.

  • browser-history-firefox:

    • request-type: manual-connection

    • reasoning: Same as above for Firefox, which stores its profile under ~/.mozilla/firefox.

Additional notes:

  • Privacy: All access is read-only. Pieces is private by design, performing all indexing and retrieval locally on-device.

  • Consent: We are requesting connection (manual), not auto-connection. This ensures users must explicitly opt-in via our doctor utility or the command line to grant these permissions.

  • Urgency: This request is associated with Revision 114, which addresses critical logging and performance issues for our enterprise users.

Requesting approval for versions 12.3.9 and 12.3.10. Thank you for your review.

2 Likes

This request has been added to the queue for review by the @reviewers team.

Hello @Pieces-Dev!

The request seems reasonable given the snap’s functionality and the fact that it concerns a manual-connection. However, because the personal-files interface is considered super-privileged, a key requirement for granting it is the Snap Publisher Vetting process.

Could you please specify if the upstream repository is public? (#askForInfo) If it is not, there is a slightly different process for vetting (see Verified Accounts).

2 Likes

Hello @yomonokio !

Thanks for the guidance!

Our upstream source is proprietary and not publicly available, so we understand that vetting needs to proceed via the Verified Accounts process. We’ve submitted that request here:

Happy to provide any additional information needed in the meantime.