Privacy policy draft

Who operates NodCue

The current App Store preparation record names ANSWER AI LAB INC as the developer. The responsible legal operator, its contact address, and a working privacy contact channel must be confirmed for the final policy. No unverified mailbox is presented as a support or privacy contact.

Data used to provide approvals

• Account and authentication: an Apple identity token is sent to the NodCue API to verify sign-in. The verified Apple subject is mapped to an account identifier. Mobile session records contain account and device identifiers, platform, token hashes, creation, expiry, last-authentication, and revocation times. The current database schema does not store the original Apple identity token. The server also exchanges the Apple authorization code and stores returned refresh tokens encrypted with an account-bound AES-256-GCM key, so it can revoke Apple authorization when an account is deleted.
• Email: the iPhone sign-in request asks Apple for the email scope. The server verifier can read an email claim from the token, but the current issuer does not save that email and the reviewed database has no account-email column. Future support correspondence and production logging require a separate review before the final disclosure is set.
• Devices and pairing: computer identifiers, pairing-code hashes, credential hashes, pairing times, revocation state, and account-level failed-attempt records are used to pair devices and limit failed attempts. The API can observe the connection IP address; the current pairing limiter groups attempts by account instead of trusting a caller-supplied source. Device records and push delivery records include APNs tokens.
• Approval content: account and computer identifiers, agent, agent-session and tool-call identifiers, tool name, reduced display summary, content fingerprint, timestamps, and decision state are stored to route and deduplicate requests.
• Activity and service operation: decision source and device, allow/deny/cancel/expiry events, execution status and optional execution message, notification events, retries, and delivery error reasons are stored to reconcile decisions and operate delivery.

These records are associated with an account; hashing a credential or content fingerprint does not make all related records anonymous.

What the Bridge sends

The reviewed adapters process the Hook input locally and send a SHA-256 content fingerprint instead of raw command bodies or file contents. Codex sends a generic tool summary. Claude file-operation summaries can contain a filename without its directory. Filenames and tool/session identifiers may themselves reveal information.

This is a statement about the reviewed adapters, not a guarantee that every accepted API field is scrubbed. The API also accepts summaries and execution messages; universal server-side redaction has not been verified. The current adapters do not send entire repositories, full terminal output, or Codex/Claude passwords or API keys as dedicated data fields. Do not put secrets in support reports or approval metadata.

Apple and other service providers

Apple provides Sign in with Apple and APNs notification delivery. APNs receives the target push token, a generic alert, and request metadata including request identifier, state, version, and expiry. The reviewed notification payload does not include the command body.

The production hosting, database, backup, network/CDN, and support-email providers and processing locations are not yet confirmed. Their access, logging, retention, and cross-border handling must be disclosed where applicable in the final policy. This draft does not claim that a particular cloud provider has been deployed.

Codex and Claude Code operate under their own providers’ terms and privacy practices. The reviewed NodCue adapters communicate with NodCue’s API; this does not describe the coding agents’ independent data processing.

Local storage and security

The iPhone stores its NodCue session in Keychain. The Mac credential store uses macOS Keychain. The current Watch implementation receives configuration and a session through WatchConnectivity and stores the session in local preferences. The server now supports a distinct short-lived Watch session linked to an iPhone session; client adoption and Watch Keychain storage remain release-review items.

The intended production transport is HTTPS. Production TLS, storage encryption, backup access, and administrative access controls have not been verified. No end-to-end encryption or absolute security guarantee is made.

Retention and deletion

Final retention periods are not set. The PRD proposes seven days for recent history, but that is not an implemented or approved deletion promise. Approval expiry and session revocation change validity; they do not erase stored rows.

The server provides an explicitly configured preview-and-execute cleanup tool for eligible completed approval requests and their associated audit, execution, and notification records. It has no default retention period or automatic schedule. Unfinished execution, pending delivery, or recent activity can keep records beyond a configured period. This tool does not erase account lifecycle records, backups, access logs, support correspondence, or third-party copies. Retention periods and operational deletion procedures for these categories remain to be approved and implemented.

The server deletion flow has been implemented and tested locally; the in-app and live Apple flows are not yet verified. It removes primary approval, audit, execution, notification, pairing, device, and session records. Apple revocation failures retain encrypted tokens and retry state until revocation succeeds. Completion removes those tokens and the separate Apple subject field, while retaining an account-linked deletion marker to prevent old sessions from recreating the account. Re-registration, the marker’s retention, backup erasure, and completion times still need approval and verification. The final policy must provide the verified in-app deletion procedure. Uninstalling the app is not a deletion request.

Analytics, tracking, and website data

No advertising, third-party analytics, or crash-reporting integration was identified in the reviewed application dependencies and source. The local support/privacy pages contain no scripts, forms, cookies, analytics, or external fonts. The final hosting platform may process IP addresses and access logs; this has not been audited.

The API logs a generic error name and startup information; database delivery errors and retry records also exist. Production proxy logs, SDK configuration, monitoring, and support-email processing remain unverified. A final no-tracking, no-sale, or diagnostics statement must be approved against the actual release and provider configuration.

Your choices and questions

You can manage notification permission in system settings and stop using the Bridge. These choices do not automatically erase account records. Before public release, a verified contact channel for access, correction, deletion, and other applicable privacy requests must be added with the identity-verification procedure.

See the support contact status. Please do not send passwords, tokens, private keys, or source code.

Policy changes

The final policy will display its effective date. Changes to collection, providers, retention, or account deletion require a new review of this page and the App Store privacy disclosures. This draft has no production effective date.