Share a vault
CollaborationAsk your agent to grant a named GitHub collaborator access to one private vault. The vault remains a git repository, and the permission maps to that repository. This is the whole of sharing in Lyt: there is no command that makes a vault readable by the world.
Grant access
Using Lyt, prepare to give GitHub user octocat write access to my research notes vault. octocat is a GitHub username, and the vault is a GitHub repository, so this grants that GitHub account access to it. Show me the exact repository and permission change, then wait for Lyt’s confirmation gate before applying it. Do not use GitHub tooling directly — go through Lyt so the gate applies.
The access change does not happen until you confirm it: the command refuses to act unless --yes is added, and that flag is the confirmation.
lyt vault share research/notes --with octocat --access writeSay read access for a collaborator who should only pull, or write access for one who can push — they map to --access read and --access write.
Every grant here names one GitHub account on one private repository. If you want a vault that anyone can read and subscribe to, you change that repository’s visibility on GitHub yourself — Lyt has no command for it, and none of the steps below produce that state.
Accept an invitation
When someone shares a vault with you, there are two halves: say yes to the invitation, then bring the vault onto your machine.
Using Lyt, show me my pending vault invitations.
A pending invitation is a normal waiting state, not a failure.
lyt vault invitesUsing Lyt, accept the pending vault invitation from GitHub user octocat. Wait for Lyt’s confirmation gate before applying it. Do not use GitHub tooling directly — go through Lyt so the gate applies.
Acceptance completes only once you confirm it: the command refuses to act unless --yes is added.
lyt vault invites --accept <invitation-id>Using Lyt, receive the vault I was just invited to: clone it onto this machine and index it so I can search it. Wait for Lyt's confirmation gate before applying it. Do not use GitHub tooling directly — go through Lyt so the gate applies.
Accepting the invitation above grants access on GitHub; it does not put the vault on this machine. This step receives it into shared/<owner> and indexes it. It refuses to act unless --yes is added, and that flag is the confirmation.
lyt vault accept-share --invite <invitation-id>One more safeguard: an agent cannot say yes for you. Acceptance and other cross-actor approval mutations fail closed over MCP. The gate is server-side and out-of-band, so it can never be satisfied from a tool call. An operator can open the dispatch side with a launch variable, but the underlying operations still refuse to complete over MCP today — so run these through the confirmation-gated CLI.
Inspect current access
Using Lyt, show me who currently has access to my research notes vault.
lyt vault access research/notesThis reads the collaborator state so you can confirm who currently has access before changing it.
Revoke access
Removing someone is the same shape as adding them: name the person, confirm, done.
Using Lyt, prepare to remove GitHub user octocat’s access to my research notes vault. Show me the exact change, then wait for Lyt’s confirmation gate before applying it. Do not use GitHub tooling directly — go through Lyt so the gate applies.
Nothing is revoked until you confirm it: the command refuses to act unless --yes is added.
lyt vault unshare research/notes --with octocatInspect the collaborator list again after it completes. Note the boundary: this removes the direct collaborator grant, but effective access through public visibility or organization and team membership is not checked. If someone still reaches the repository that way, revoking here will not close it.