Optional read-only copies of selected status and usage on another environment

[Benniphx]

I use T3 across several devices. After a laptop sleeps, I would like another
client to read its previously exported task status and usage from an environment
that remains online. A local cache helps a client that already read those data;
the additional use case is an enrolled client without its own source cache.

For example, source A explicitly exports selected metadata to trusted environment
H while A is online. After A sleeps, an already authorized phone reads A's last
acknowledged copy from H, labelled with source, export time and expiry. Updates
that A never exported would remain unavailable. A still owns all execution and
settlement; the copy would be read-only.

Related work considered in the AI-assisted investigation:

• #3795 adds durable
  local server configuration and Git refs.
• Ideas #16722 and
  open PR #15902 include saved
  usage in the current browser. The additional question is an explicitly
  approved copy served by another online environment to a client without that
  local saved usage.
• #9114 makes clear that
  offline behavior is not currently a priority. I understand that this may
  also place this narrower use case outside current priorities.

The smallest scope I would like direction on is opt-in export of selected
thread-list status to one chosen environment. Exact-window usage could be a
second separately approved slice. Even status exports include thread titles
and project names; usage adds provider home paths and device/volume identifiers,
which is another reason to agree on it separately. No messages, files, raw transcripts, provider
credentials, settings sync, offline commands or writable replicas.

The authorization model needs agreement before an upstream implementation:
explicit source export consent, separately authenticated readers, bounded
leases, and visible revocation delay. Existing connection access would not
silently authorize redistribution. A live source or known direct access denial
would take precedence; expired or unauthorized copies would be unavailable.
Usage, if included later, must retain source identity, coverage and pricing
quality and must never be added to its own live copy.

An AI-assisted private experiment has been tested with synthetic data.
Its coding conventions, capability checks, durable storage path and user guide
are being checked separately from the product decision. I would adapt an
upstream implementation to the scope you approve rather than assume the whole
experiment is the right shape.

One authorization question matters for the first slice: the private pilot
enrolls an exact native session. An isolated browser restart
retained its session and copy; that does not establish continuity for every
client or credential. Desktop credential replacement and T3 Connect token renewal
issue new session IDs. A transparent reader identity across those changes would need
an issuer-authenticated account/device/link identity and agreed revocation
semantics. Matching labels, generic subjects or a device key alone would not
be sufficient. Would an explicit-session pilot be useful, or should stable
reader identity be a prerequisite? If this belongs in core, should setup use the
existing guarded RPC commands and agent tools rather than a separate HTTP
management surface? Native mobile acceptance and hosted-relay
end-to-end coverage are not claimed for this experiment.

Would maintainers consider this direction, and if so, what first slice and
reader/lease model would fit T3? If offline availability should remain local
to each client, I can keep the experiment external. I will wait for explicit
direction and scope approval before opening an upstream PR, as requested by
CONTRIBUTING.md.

Prototype implemented with GPT-6.1-Sol through the Codex harness in T3 Code;
bounded cross-model reviews with Claude Sonnet 5.5. Proposal prepared with
GPT-6.1-Sol in Codex through T3 Code.

[Benniphx]

Hi maintainers, a gentle follow-up after a week: would an opt-in, read-only export of selected thread-list status to one trusted environment be a direction you'd consider? Usage would stay out of the first slice.

If so, would explicitly enrolling readers per native session be acceptable for an initial pilot, or would stable reader identity across credential renewal be a prerequisite? I will wait for explicit direction and scope approval before opening an upstream PR. If this does not fit current priorities, that guidance would also help. Thanks for your time.

[jacobcorbett]

I hit the same problem: my computers have seen the latest settle/snooze state, but my phone shows an older list once the source laptop is off. I would like maintainer approval for the direction and scope before opening an upstream PR, as CONTRIBUTING.md requires.

I have a working implementation on my fork: PR #1, with screenshots, tests and limitations. The proposed first slice is:

• The user chooses one linked environment to hold a read-only copy of the source's thread list.
• A client that obtained a reader grant from the source can fetch a newer copy while the source is unreachable. Live source data wins on reconnect; a known access refusal does not trigger fallback.
• Web, desktop and mobile have setup controls and an offline/last-synced notice. Commands and execution still belong to the source. Conversation bodies and usage are excluded; titles, status, times, project folders, branches and pull-request metadata are included.

Local checks and a real browser pass with two isolated servers verified newer settle/snooze state after the source stopped, reload persistence, turning sharing off, and live-state replacement on reconnect. Native mobile, packaged desktop, hosted relay and credential-renewal flows remain unverified.

The current trust model has limits worth agreeing on first: reader grants are session-specific; copies expire after seven days; revocation reaches the host on the next successful export. Writer ownership uses a persistent secret trusted on first claim by an approved peer, so an approved peer could pre-claim an unused environment ID.

Would you approve this direction and first-slice scope for an upstream PR, or should stable reader identity or stronger source identity be prerequisites? I can narrow or adapt the implementation to the scope you approve. I will keep the PR on my fork until then.

Implemented with Claude Sonnet 5.5 through Claude Agent and GPT-6.1-Sol through Codex in T3 Code.