Privacy

Who is responsible for your data

Kent C. Dodds, operator of Kody at heykody.dev, is the data controller for the hosted service. You can reach the operator at support@heykody.dev. A separately operated Kody deployment has its own operator and data controller.

What Kody stores per account

Each signed-in user gets a fully isolated assistant. Kody stores account profile information (email and username), secrets, values, memories, packages and their source, jobs, email inboxes and messages, durable storage, remote connector configuration, OAuth grants, package invocation tokens, and any platform feedback you approve for submission. All of this remains scoped to your account except for the narrow admin review of approved platform feedback and the community activity metadata described below.

What a deployment admin can see

On shared deployments, operators can grant an admin role for account administration. Admins see account metadata only: user id, username, email, created and updated timestamps, and role assignments. The admin UI lists users and roles; it does not expose account content. Platform feedback you explicitly approve for admin review is a narrow user-content exception.

Admins also moderate public community listings and attributed community reports, and can see who forked or rated a public listing, when, and the rating scores. One-click installs appear as forks because both use the same activity record. This view and admin-configured notifications never include private package source, rating notes, email, stable user ids, secrets, or unrelated account content.

Platform feedback

An agent may briefly describe Kody friction and ask whether you want it submitted. Nothing is submitted unless you explicitly approve. Feedback is attributed to your account and is not anonymous. Once you approve, the exact approved summary and details and your account user id, username, and email may be delivered immediately to admin review tools and admin-configured notifications such as Discord. No unrelated account content is delivered. Notifications can deep-link an admin to the read-only platform-feedback review surface. Admins can read and triage only the approved submission, and agents must omit secrets and unrelated private content.

Each account can create at most 10 feedback submissions in a rolling 24-hour period and have at most 100 active submissions (open or triaged). Open and triaged feedback remains until it is resolved, dismissed, or your account is deleted. Resolved and dismissed feedback is removed 365 days after its last update. Your account export includes your submissions and their status, but not internal reviewer identity, notes, or timestamps. Account deletion removes any remaining submissions.

When a notification is still queued, Kody rechecks that the feedback exists immediately before delivery and cancels it after account deletion when possible. Kody cannot recall a copy already delivered outside Kody. Admin notification copies, including Discord messages, may remain after Kody account deletion under the deployment operator's retention and deletion controls. Those copies contain only the exact approved feedback and its attribution, never unrelated account content.

What an admin can never see

The admin role is not a general data-access role. Approving platform feedback does not let admins browse:

• Secret values or secret metadata (names, scopes, allowlists)
• Package invocation tokens
• Values
• Memories
• Private packages and their source
• Jobs
• Email inboxes and messages
• Durable storage contents
• Remote connector configuration
• OAuth grants

None of this appears in any admin endpoint, page, or API payload — not even in redacted or count form — with one qualified exception: platform maintenance codemods, described next, surface package identity, affected file paths, and fixed migration messages (never file contents).

Platform maintenance (package codemods)

When the platform's package API changes, Kody migrates published package source with package codemods: versioned, deterministic transforms that live in the open-source repository and ship through code review like any other platform change. Nobody can author an ad hoc transform through the admin surface — admins only choose when a published, reviewed codemod runs, and can scope it to a dry run first.

A codemod apply rewrites only what the reviewed transform matches, republishes the package through the same checks as a normal publish, records a codemod(<id>) commit in the package's own git history, keeps a revert snapshot, and dispatches a package.codemod.applied (or .reverted) event your packages can subscribe to. Fleet runs are audit-logged.

Running a codemod never shows an admin your source. Scan and run results expose only package identity (ids), affected file paths, and the codemod's own fixed finding messages — codemods are forbidden from embedding file contents in their findings. Ambiguous matches are skipped and reported for the owner rather than rewritten.

How long Kody keeps data

Account content such as packages, secrets, values, memories, jobs, and durable storage remains available while your account and that content exist. You can delete individual content or the whole account. Some operational records have fixed cleanup periods:

• Email delivery events: 90 days
• Email messages and their attachments: 365 days
• Completed workflow runs and conversation-suppression records: 90 days
• Resolved or dismissed platform feedback: 365 days after its last update; open or triaged feedback remains until it is resolved, dismissed, or the account is deleted
• Audit events: 180 days
• Feature-flag exposure records: 90 days
• Daily entitlement counters: 400 days
• Monthly usage rollups: 24 months
• Stripe webhook event records: 30 days
• Non-current published bundle artifacts: at least 30 days, then eligible for removal when no active source or repo session needs them

Deletion from a subprocessor's backups or logs follows that subprocessor's own retention cycle. Records may be kept longer when required by law, needed to resolve a dispute, or necessary to protect the service from abuse.

Service providers

Kody uses these subprocessors to run the hosted service. They process only the data needed for their role:

• Cloudflare — application hosting, database, object storage, email delivery, security, and network infrastructure
• Stripe — paid subscriptions, billing, and payment records
• Kit — waitlist and product email subscriptions when you submit your email for those purposes
• Sentry — application error reporting and operational diagnostics
• Fathom — privacy-focused website traffic analytics

Your choices and rights

Use Account settings to export a copy of your Kody data or delete your account. You can also ask to access, correct, delete, restrict, or receive your personal data, or object to its processing, by emailing support@heykody.dev. Which rights apply depends on where you live. We may need to verify your identity before acting on a request.

Deployment operator access

Role-based access controls the application surface. Whoever operates the deployment — holding the Cloudflare account, D1 database access, and SECRET_STORE_KEY — sits outside any application-level control. The admin role grants no infrastructure access, and infrastructure access requires no admin role.