Choose and Change an Access Deadline

People grants, guest links, request approvals and public Funnel use a shared lifetime policy. Choose a duration or an absolute deadline; operational waits and timeouts use their separate syntax.

Minimum lifetime is 1h from the operation. New people grants and Funnel default to 24h; guest creation and approval require an explicit chosen lifetime. Guest/public maximum defaults to 7d; eligible members have no finite policy maximum. never is refused for new guest/public exposure, even with acknowledgement.

Relative units must be unique and descend in order (w,d,h,m,s,ms,us,ns), without signs or spaces. Days mean 24 elapsed hours. An offset-free absolute time uses the operator process's local timezone, including MCP, not the recipient's timezone. A date means the start of that local day. Ambiguous or nonexistent DST times are refused: supply an RFC3339 offset. Stored deadlines are UTC.

Change one app's deadline

tslink people add alice@example.com --apps photos --for 90m
tslink people update alice@example.com --until 2030-06-01T18:00:00Z
tslink extend photos --person alice@example.com --for 36h
tslink extend photos --person alice@example.com --for 1h --regrant
tslink extend preview --for 3d

--for and --until are mutually exclusive. extend with --person changes one grant; without it, it selects Funnel. It always returns the versioned JSON envelope. Relative extension sets now + duration, not old deadline + duration, and can shorten access. Expired deadlines or durable expiry latches require --regrant; it never clears a person's revocation tombstone. An expired acknowledged Funnel downgraded to private can be reactivated explicitly; an operator-disabled, still-unexpired Funnel cannot.

People update --apps preserves retained deadlines and gives new apps 24h. An update without expiry keeps existing deadlines, including legacy permanent state. Invitation history makes a person a persistent guest for duration policy; accepting an invitation is not inferred as membership. First inviting an existing member checks retained deadlines against guest limits. Retry invitations without silently renewing them. Scoped grants also obey max_duration and binding expiry. Guest IDs cannot be renewed with extend: issue a new guest grant.

Owner policy

Edit config.json, preserving other fields:

{"durations":{"public_max":"14d"}}

Omit the block for 7d. The value must be a relative lifetime of at least 1h; invalid or unknown configuration fails closed. Changes affect subsequent operations, not stored deadlines. If the maximum is below the 24h default, supply an explicit allowed duration. This policy also caps persisted guests.

url --wait, logs --since, credential expiry metadata, health/upload timeouts and MCP keepalive are operational values, not share/access lifetimes. Their limits and grammar remain separate. Access-history filters accept positive Go duration/RFC3339 bounds, not this whole lifetime grammar.

Related: People · Guest links · Requests · MCP scopes.

Sources: TSLink durations.md