Tebby Code Policy

Tebby Code is an AI coding agent for Tebstack stores. When you connect a GitHub repository, it can take a bug report, read your code to diagnose the problem, and — only after a member of your staff approves the diagnosis — propose a fix as a GitHub pull request for your team to review and merge.

Two principles govern everything below, and the rest of this policy is an application of them:

• Your code stays yours and stays in place. Tebstack never keeps a copy of your repository. Code is read inside a temporary, isolated sandbox that is destroyed after each job. The fix lives in your own GitHub repository as a pull request.
• A human is always on the gate. Nothing touches your code, and no pull request is opened, until a member of your staff approves. Tebby Code proposes changes; it never merges them.
• Not trained on, not shared, only kept temporarily. Your code is never used to train any AI model, is never sold or shared with third parties for their own purposes, and is processed in isolation. The limited workflow data we do keep is stored only temporarily and deleted automatically (see Sections 5 and 7).

A Tebby Code job moves through a fixed, gated pipeline. Each stage is recorded so your staff can see exactly what happened:

• 1. Intake. A bug report is filed — manually, or routed in from a connected source such as your support chat or a Discord channel. We store the report's title and body and match it to one of your connected repositories.
• 2. Triage (read-only). An isolated sandbox clones the repository using a read-only token and an AI agent reads the relevant source to produce a diagnosis: a verdict (real bug, user error, or needs more info), a root cause, a proposed fix plan, and supporting evidence such as file paths, line references, and short code or log excerpts. Triage never modifies your code.
• 3. Staff review & approval. A real-bug diagnosis is held at an approval gate in your dashboard. A staff member with the appropriate permission reviews it and approves, rejects, or asks Tebby to take a different approach.
• 4. Fix (only after approval). On approval, a fresh sandbox clones the repository using a write-scoped token, the agent implements and verifies the change on a new branch, and pushes that branch to your repository.
• 5. Pull request. Tebby Code opens a pull request from that branch. If the agent could not self-verify the change, the pull request is opened as a draft and flagged for review. The merge decision is always yours.
• 6. Optional follow-ups. After a fix is merged, or when triage concludes the report was a user error, Tebby Code may draft a documentation/FAQ entry. Like code, drafted documentation is never published automatically — it lands as a pending proposal for your staff to approve.

Tebby Code accesses your code through a GitHub App installation that you authorize. You choose which repositories the installation can access, and you separately choose which of those repositories Tebby Code is allowed to work on. You can change or revoke this access at any time from GitHub or from your Tebstack dashboard.

Access is least-privilege and short-lived. For each job we mint a fresh access token scoped to the single repository involved, with only the permissions that stage needs, and it expires shortly after. The scopes are:

The GitHub App also subscribes to pull-request events so it can tell when a Tebby Code pull request is merged or closed and update your dashboard accordingly. It does not receive or act on events for pull requests it did not open. Access tokens appear only inside the sandbox at the moment a repository is cloned; they are redacted from any stored logs.

Your code is not sold, is not shared with any third party for their own purposes, and is never used to train any AI model. It is processed in isolation, only to perform the work you request. Doing that requires a small number of sub-processors that act strictly on our behalf and only for that purpose; they do not use your code to train AI models:

• Anthropic, PBC (AI processing). To produce a diagnosis or a fix, the bug report and the repository content the agent reads (the specific files it opens, search results, and relevant excerpts) are sent to Anthropic's API for inference. Under Anthropic's Commercial Terms of Service, API inputs are not used to train its models, and the transfer is governed by Anthropic's Data Processing Addendum, which incorporates EU Standard Contractual Clauses. See Anthropic's Privacy Policy.
• Cloudflare, Inc. (execution). The control plane and the isolated sandbox in which your repository is cloned and the job runs operate on Cloudflare's infrastructure. Your code is processed there transiently, in the sandbox's ephemeral storage, for the duration of a single job only, and Cloudflare does not retain it or use it for any purpose of its own.
• GitHub, Inc. (Microsoft) (source of record). Your repository lives on GitHub, and Tebby Code reads from and writes pull requests to it through the GitHub App. GitHub's handling of your repository is governed by your own agreement with GitHub.
• Intake sources. Where you route bug reports in from your support chat or a Discord channel, the report text and a reference to the relevant product or repository are sent from that source to the Tebby Code control plane to start a job.

Beyond these sub-processors, your code and developer data are not shared, sold, disclosed, or used for advertising or model training. The only exception is a disclosure we are legally required to make, as described in our Privacy Policy.

Tebstack does not store a copy of your repository or its source code. For each job, the relevant repository is cloned into a temporary, isolated, single-use sandbox (a Cloudflare Container). When the job finishes — whether it succeeds or fails — the sandbox is torn down and its working copy, including the cloned code, is permanently deleted. There is no persistent checkout, mirror, or backup of your code on Tebstack's systems.

What we do keep — only temporarily — are the limited artifacts needed to show your staff what happened, to bill accurately, and to operate the workflow. These are stored in our database under the same per-store access controls (row-level security) as the rest of your store's data, and are deleted automatically after a short retention period (see Section 7):

• The bug report — the title and body submitted for triage.
• The diagnosis — verdict, confidence, reproduction steps, root cause, and fix plan, plus supporting evidence that can include file paths, line references, and short excerpts of code or logs that Tebby cites to justify its conclusion. This is a diagnostic record, not a copy of your repository.
• Job records and logs — status, timing, the AI model used, and execution logs, with access tokens and other secrets redacted.
• The proposed change as a diff — the unified diff of an applied fix, captured to render the change summary in your dashboard. It is size-capped (large diffs are truncated) and token-redacted. The full change always lives in your GitHub pull request.
• Pull-request metadata — number, URL, branch name, and state (open, merged, or closed).
• Repository references — the GitHub App installation identifier, repository name, and default branch for the repositories you connect. This is a pointer, not the code.

Because a diagnosis and a diff can quote small portions of your code, those excerpts are stored — temporarily — and then deleted. Your repository as a whole is never stored, and none of this data is used to train any model.

The approval gate is the core safety control of Tebby Code, and it is enforced by the system, not left to convention:

• Triage is strictly read-only. The token used for triage has no write permission, so triage cannot modify your repository even in principle.
• An issue cannot enter the fixing stage from any path other than an explicit approval. Nothing writes to your code before that approval.
• Write access is granted only at the moment a fix is dispatched, scoped to the one repository, and is short-lived.
• Tebby Code opens pull requests; it never merges. When the agent cannot self-verify a change, the pull request is opened as a draft and flagged so a human reviews it before it can be merged.
• Drafted documentation arising from a fix or a user-error diagnosis is also gated — it is never published without staff approval.

Which staff members may view diagnoses and approve fixes is controlled by your store's staff permissions. You are responsible for granting these permissions appropriately.

The cloned source code is never retained beyond a single job's sandbox. The workflow artifacts described in Section 5 — the bug report, the diagnosis and its excerpts, job logs, the stored diff, and pull-request metadata — are kept only temporarily: they are deleted automatically within 30 days of the related Tebby Code job completing. After deletion they are purged from our active systems; any residual copies in encrypted backups are overwritten on our normal backup-rotation cycle.

Data is also removed sooner when you delete an issue, disconnect the repository, or close your account. Disconnecting a repository stops any further processing of it, and revoking or uninstalling the GitHub App immediately ends Tebstack's ability to access the affected repositories.

Tebby Code is built with the following safeguards:

• Each job runs in an isolated, single-use sandbox that is destroyed after the job, so no job can observe another's code or state.
• Repository access uses short-lived, least-privilege tokens scoped to one repository, minted per job (see Section 3).
• Tokens and secrets are redacted from stored logs and from the stored diff.
• Stored Tebby Code artifacts are protected by database row-level security, so only your store's owner and authorized staff can read them. Tebstack does not use a privileged service-role key to bypass these controls.
• Data in transit is encrypted with TLS, and inbound webhooks from GitHub are verified by signature.

No system is perfectly secure. If you discover a vulnerability, please disclose it responsibly by emailing legal@tebstack.com.

• Authorization. Only connect repositories you own or are authorized to access and modify, and only use Tebby Code in a way that complies with GitHub's terms and any third-party licenses applicable to your code.
• Review before merging. Tebby Code is an assistive tool. You are responsible for reviewing, testing, and deciding whether to merge any proposed change, and for the consequences of merging it.
• Secrets in code. If a connected repository contains secrets or personal data in its source or history, that content may be read during a job. We strongly recommend not committing secrets to source control and rotating any that are exposed.
• Disclosures. Ensure that any personal data contained in bug reports you submit is covered by appropriate disclosures to the individuals concerned.

AI-generated diagnoses and code may contain errors, may be incomplete, or may not be appropriate for your environment. Tebby Code does not guarantee that any diagnosis is correct or that any proposed change is correct, secure, performant, or fit for any particular purpose. It is a tool to assist your engineers, not a replacement for human review.

To the fullest extent permitted by law, Tebby Code is provided "as is," and the disclaimers and limitation of liability in our Terms of Service apply in full to your use of it. In the event of any conflict between this policy and the Terms of Service, the Terms of Service govern.

We may update this policy as Tebby Code evolves. When we make material changes, we will update the effective date above and, for significant changes, notify you by email or a prominent notice in the Services. Your continued use of Tebby Code after changes take effect constitutes acceptance of the updated policy.

If you have questions about how Tebby Code handles your code or data, please contact us: