You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Cross user interaction data aggregation may lead to user preferences/information leakage #11
Will this process result in User A indirectly obtaining User B or User C's personal information, work habits, or environmental preferences when using the updated skills?
Thanks for your comment. At present, users in the same sharing group may indirectly receive environment-specific knowledge distilled from other users' sessions. The current pipeline does not yet include a dedicated privacy-redaction stage before shared skills are published. A future direction is to reduce this risk by moving from raw session sharing toward privacy-filtered, minimal-evidence sharing.
Yes: when sessions from A/B/C enter the same evolution group, generated skills can contain personal/environment-specific details from those sessions. Group IDs and aliases are not anonymization or access controls.
To choose a meaningful isolation policy, do you need to prevent disclosure between users in the same group, or only between separate groups? Are user/session text and tool outputs allowed to leave each machine at all? Those requirements determine whether shared raw-session evolution is appropriate. I am adding an explicit session-upload disable switch so skill synchronization can be used without exporting sessions; this is a data-flow control, not a promise that previously shared skills have been anonymized.
The session-upload control is now merged in #101. Set sharing.upload_sessions: false and restart the proxy to keep skill push/pull while disabling periodic and final session exports, including exports to a local shared folder. Fresh setup explicitly asks before enabling upload (default no); existing installations preserve their behavior until changed. Six new regression cases cover no storage access/no evolve trigger and continued skill pull.
This is a concrete mitigation, not anonymization: it does not delete previously exported artifacts, prevent local recording/inference requests, or inspect personal details already present in skills. Keeping this issue open for the trust boundary and redaction requirements requested above.
Activity
Upper9527 commentedon Apr 21, 2026
Thanks for your comment. At present, users in the same sharing group may indirectly receive environment-specific knowledge distilled from other users' sessions. The current pipeline does not yet include a dedicated privacy-redaction stage before shared skills are published. A future direction is to reduce this risk by moving from raw session sharing toward privacy-filtered, minimal-evidence sharing.
Upper9527 commentedon Oct 21, 2026
Yes: when sessions from A/B/C enter the same evolution group, generated skills can contain personal/environment-specific details from those sessions. Group IDs and aliases are not anonymization or access controls.
To choose a meaningful isolation policy, do you need to prevent disclosure between users in the same group, or only between separate groups? Are user/session text and tool outputs allowed to leave each machine at all? Those requirements determine whether shared raw-session evolution is appropriate. I am adding an explicit session-upload disable switch so skill synchronization can be used without exporting sessions; this is a data-flow control, not a promise that previously shared skills have been anonymized.
Upper9527 commentedon Oct 21, 2026
The session-upload control is now merged in #101. Set
sharing.upload_sessions: falseand restart the proxy to keep skill push/pull while disabling periodic and final session exports, including exports to a local shared folder. Fresh setup explicitly asks before enabling upload (default no); existing installations preserve their behavior until changed. Six new regression cases cover no storage access/no evolve trigger and continued skill pull.This is a concrete mitigation, not anonymization: it does not delete previously exported artifacts, prevent local recording/inference requests, or inspect personal details already present in skills. Keeping this issue open for the trust boundary and redaction requirements requested above.