Problem
aware connect --list --json reports credential status/expiry but not the scopes actually granted or an opaque credential generation. A caller can request --scopes, observe only a zero exit code, and later see status: valid, but cannot prove the current stored credential has a write scope or that it is still the credential for which a local readiness marker was created.
This blocks safe capability discovery for write-mode workflows such as Gmail gmail.send and Microsoft 365 outlook.mail.send. Treating any valid Google/Microsoft token as send-capable advertises a capability that may fail for missing consent; persisting a caller-owned “scoped connect succeeded” marker becomes stale if AWARE refreshes or replaces the credential outside that caller.
Reproduction
aware connect --help
aware connect --list --json
The connect command accepts --scopes; the list response contains integration, status, source, expiry, app, flows, and recommended flow, but no granted scopes or credential generation.
Expected
Expose non-secret credential capability metadata through the AWARE-owned surface, for example:
- normalized granted scopes (or a provider-agnostic capability list), and
- an opaque generation/fingerprint that changes whenever the stored credential is replaced, refreshed into a materially different grant, or removed.
OAuth/device-code completion output should return the same generation so a consumer can bind readiness to the credential that was just granted. Tokens must remain secret and never enter the consumer process.
Downstream
Required for truthful connected-mailbox readiness in pawellisowski/floless.app#1090.
Problem
aware connect --list --jsonreports credential status/expiry but not the scopes actually granted or an opaque credential generation. A caller can request--scopes, observe only a zero exit code, and later seestatus: valid, but cannot prove the current stored credential has a write scope or that it is still the credential for which a local readiness marker was created.This blocks safe capability discovery for write-mode workflows such as Gmail
gmail.sendand Microsoft 365outlook.mail.send. Treating any valid Google/Microsoft token as send-capable advertises a capability that may fail for missing consent; persisting a caller-owned “scoped connect succeeded” marker becomes stale if AWARE refreshes or replaces the credential outside that caller.Reproduction
The connect command accepts
--scopes; the list response contains integration, status, source, expiry, app, flows, and recommended flow, but no granted scopes or credential generation.Expected
Expose non-secret credential capability metadata through the AWARE-owned surface, for example:
OAuth/device-code completion output should return the same generation so a consumer can bind readiness to the credential that was just granted. Tokens must remain secret and never enter the consumer process.
Downstream
Required for truthful connected-mailbox readiness in pawellisowski/floless.app#1090.