Encrypted file uploads

Requires c6s v0.9.19 or later. Update with brew upgrade c6s-cli, or repeat the standalone installer. Check c6s attachment upload --help.

Upload to an existing item

Sign in, enroll your CLI device and connect its vault first. Find the existing remote item, then upload an authorized local file:

c6s item list --remote --json
c6s attachment upload REMOTE_ITEM_ID --file /path/to/settings.json --json
c6s attachment list REMOTE_ITEM_ID --json

Replace REMOTE_ITEM_ID with the ID returned by the remote list. For multiple accounts, prefix each command with c6s --profile PROFILE instead of changing the shared default. Upload writes directly to the connected vault; you do not need to run c6s vault upload afterward. Other clients see it after their normal sync.

This adds one attachment; it does not replace another file or change item fields. The CLI encrypts contents, filename and media type locally. Success reports the attachment ID, revision, size, policy and ready state, never file contents. Regular files up to 16 MiB minus 28 bytes are accepted; directories and symlinks are rejected. Binary bytes and every line ending are preserved.

Filename and agent policy

• --name overrides the encrypted display filename; default is the source basename.
• --media-type defaults to application/octet-stream and never changes the bytes.
• --agent-policy reference_only is the default. never_agent excludes agent use.
• --agent-policy approved_injection makes this file eligible for a later exact approval request. It does not approve or execute anything by itself.

For approved execution, use the returned exact item/attachment/revision with c6s request create --inject-file. The existing human approval and one-time grant remain required. Never paste file contents into a prompt or put them in arguments.

Change an existing file's policy

Requires v0.10.5 or later and c6s attachment policy --help. Inspect the current ready attachment and explicitly choose its policy; do not delete and re-upload it:

c6s --profile PROFILE attachment list REMOTE_ITEM_ID --json
c6s --profile PROFILE attachment policy REMOTE_ITEM_ID ATTACHMENT_ID \
  --revision CURRENT_REVISION --agent-policy approved_injection --json
c6s --profile PROFILE attachment list REMOTE_ITEM_ID --json

Replace the IDs and revision with the inspected metadata. The command preserves the attachment ID, filename, media type, exact bytes and line endings. It reseals the unchanged file locally at the next revision without printing plaintext or writing a plaintext staging file. A matching policy is a no-op. A stale revision, unfinished upload, changed file or missing parent stops the operation.

The private ciphertext-only policy journal is saved before any remote write. The file may be temporarily unavailable while its replacement finishes. After a transport interruption, keep the journal and resume that exact operation:

c6s --profile PROFILE attachment policy --resume /exact/policy-journal.json --json

Do not use attachment upload --resume for a policy journal. Do not edit the journal or repeat a new policy mutation to bypass a conflict. The source file is not needed. Verify the resulting policy, next revision and state: ready through metadata. Use that new revision in a separately approved --inject-file request; an old revision or approved_injection alone does not authorize execution.

Resume an interrupted upload

Before the first remote write, c6s saves a private ciphertext-only journal and reports its path. Use --journal /path/to/new-journal.json to choose a new location; existing files are never replaced.

If connectivity fails, retain the journal and resume under the same profile:

c6s attachment upload --resume /path/to/journal.json --json

Resume reuses the original ID and encrypted bytes, even if the successful response was lost. The original source file is no longer needed. Do not repeat the original --file command unless you intend to create a second attachment. Do not edit the journal or combine resume with item, file, name or policy options.

On attachment_conflict, stop and inspect remote metadata; do not delete/recreate the item or use vault reconciliation. On attachment_journal_invalid, verify the original profile/vault rather than modifying the journal. Errors go to stderr; --json keeps successful machine-readable metadata on stdout.

Once ready has been confirmed, you can remove the completed retry journal. It contains encrypted file data, so do not attach it to a public support ticket. It is a retry record, not a portable backup or an approval grant.