Graphide Privacy Policy

1. Who we are

Graphide, Inc. is a Delaware corporation with a business address at 2215 Channing Way, Berkeley, CA 94704, United States. For the data described here we are thecontroller, which means we decide what is collected and why. You can reach us at hello@graphide.com.

PLACEHOLDER, counsel to confirm the entity's incorporation details, and whether Graphide is a controller, a processor, or both for each category below.

2. What this policy covers

Graphide is two things that collect data, and this policy covers both.

• The product. Graphide Editor, the gr command line tool, the grug local daemon and the hosted API.
• The website. graphide.com (graphide.net, its former name, redirects to it), including the alpha signup form and the feedback questionnaire.

It does not cover a third party's own product that you sign in to through Graphide. If you use your own subscription to another provider inside the editor, that relationship is between you and that provider and their policy governs it.

3. What we collect

3.1 Account data

Your user id and your email address, received from the sign-in token issued by Supabase and stored in our database. We never see your password: Supabase runs the sign-in flow, not us.

3.2 The graph replica

Graphide reads your source files on your own machine to build the graph.The client does not upload them, and the server does not store them: the upload routes it once used (POST /sources, POST /sources/negotiate) now refuse every request with 410 Gone, and the server's retention sweep deletes any stored source file on every pass.

What does upload continuously in the background, once you are signed in and have a workspace open, is the graph replica: every node, tag, edge, criticality mark, source state and span that Graphide extracted from your code. In practice that is every symbol name, function signature, short string constant pulled from a function body, model-written description and file path in the project. It lands as a database file per workspace on our server.The replica carries short excerpts of your code, never whole files.

This is not telemetry and the telemetry settings do not stop it.It is how the cloud half of the product works. Signing out stops it mid-session, without restarting anything.

3.3 Interaction signals for ranking

One row per interaction with your graph: the node, the signal, its source, a weight, a timestamp and a session id. The nine signals are open,click, dwell, edit, revert,mention, search_click, explain_request andagent_read.

Stated plainly, because it is the item most likely to surprise someone: this is a record of which parts of your own codebase you looked at, for how long, and when. It is used to rank what matters in the graph.

3.4 The diagnostic event stream

Structured events about how the software is behaving: process starts and stops, init and sync passes with their timings and counts, cloud request routes and status codes, tool names and durations, error text and stack traces, model names and token counts, command names and exit codes, editor and canvas events. Each event carries a per install identifier, a session id, the build, the operating system and the architecture, and a hash of your workspace root path rather than the path itself.

Diagnostic events also carry file names, symbol names and paths. They do not carry the contents of your files.

A narrow slice of these events also goes to PostHog, the product analytics service listed in section 8, so we can see which features are used. Our API forwards only events on a fixed allowlist, and only these kinds:

• which features and commands you use, when an editor window opens or closes or the local daemon starts or stops, how long an editor window took to start, and which editor version and build it runs;
• when you set up a project, whether setup finished, whether agent tool setup was installed or skipped, and the project health check result as a status and a count of failing checks;
• when you remove Graphide's data from a project, whether anything was removed, how, and whether the server copy was erased (a status, never the folder);
• agent turns, with the model name and the token and cost counts;
• which outside agent tools connect to your graph, when their sessions start and end, how many prompts they take (a count, never the prompt) and how you answer their approval prompts;
• when a graph build starts and finishes, and how large the graph is, as counts of nodes, edges and code symbols;
• the update and sign in funnel: update attempts and their results, the version you moved to, and which sign in provider you use.

Each one carries your install identifier, your account id when you are signed in, the app version, the operating system and its architecture, and session and window ids. None of the session content in 3.5, and no file paths or other free text, with one exception: the message of an error report, described below, which is scrubbed first. The editor does not connect to PostHog itself: our API sends these events after it receives them, so PostHog is not given your IP address for them.

Only at the full level. Events go to PostHog only from an install whose telemetry level is full and whose latest answer to the first run notice was to the version that first names PostHog (2026-09-29.1) or a later one. An install that has not answered that notice yet sends nothing to PostHog. At diagnostic and off nothing goes to PostHog, and GRAPHIDE_TELEMETRY and DO_NOT_TRACK, described in section 6, apply to it as they do to the rest of telemetry. Screen recordings of the editor, which also go to PostHog, are a separate matter with a later notice version (2026-09-30.2). They are described in 3.11.

Error reports also go to PostHog, so that errors are grouped and we are told when a new one appears or an old one returns. An error report holds the error's type and message and its stack trace: where in Graphide's own code it happened. Before it is sent, our API takes out file paths and file names from your machine, keys, tokens, email addresses, and everything after the host name in web addresses. The parts of a stack trace inside Graphide's own code keep their paths, which name our files, not yours. Error reports carry the same identifiers as the events above, without your IP address, and are sent only from an install whose telemetry level is full and whose latest answer to the first run notice was to the version that first names them (2026-10-03.1) or a later one. The same errors still go to Sentry as described in 3.6.

The usage ping, sent at every level. So that we know how many people use Graphide each day and for how long, the local daemon sends one small event,usage.heartbeat, for each five minute window in which you or an agent you connected did something in Graphide: opened an editor window, used the canvas or a command, answered an approval, prompted an agent, connected an agent over MCP or ran a gr command. It is sent at every telemetry level, offincluded. It carries your install identifier, your account id when you are signed in, the session id, the build, the operating system and its architecture, the time, and one yes or no: whether a person, rather than only an agent, acted in that window.Nothing else: not what you did, not which command, feature or project, no file names, paths, prompts or any other text. It goes to us alone, never to PostHog or Sentry, and it is kept with the diagnostic events (section 7). The server's own kill switch, which we use to stop all telemetry from every install, stops it too.

3.5 The session content stream

This is the category that matters most, and it is on by default.Graphide uploads the substance of your sessions, each item cut to at most 4 KB (4,096 bytes) before upload:

• your prompts, as you typed them;
• the model's completions;
• every tool call with its arguments, and every tool result with its content;
• your edits, as diffs.

The server enforces the same 4 KB cap on anything it receives. Each item carries a turn id, so a whole session reassembles.

Secrets are stripped before anything is uploaded. The scrubber removes Authorization headers, any bearer value, values shaped like a JSON web token, sk-, sk-ant- and AKIA style keys, PEM blocks and environment variables, and it replaces the contents of files named .env, *.pem, *.key andid_rsa* with a redaction marker in tool results and edits.The rest of your code is not stripped. Scrubbing removes credentials, not content.

Who it is attributed to. When you are signed in, content and diagnostics carry your account id. When you are not, they carry only a random per install identifier created on first run, and the record is stored with no account attached. We accept reports from a signed out install deliberately, because the two failures we most need to see, "it would not start" and "sign-in failed", both happen before there is an account. Signing in later does not attach earlier signed out records to you.

You can turn this stream off and keep the rest. See section 6.

3.6 Crash and error reports

Unhandled errors, panics and crashes from the daemon, the CLI, the agent worker, the API and the editor extension host go to Sentry. A report carries the stack trace and exception message, the build identifier, the per install identifier and breadcrumbs, with the same scrubbing rules applied. A stack trace can still contain a file path from your machine. At the fulllevel, errors from the daemon, the CLI and the editor also go to PostHog as the error reports described in 3.4, with file paths from your machine taken out.

3.7 Website signup and feedback

If you use the signup form we collect your email address and yourmessage. If you complete the feedback questionnaire we collect your answers, including free text, plus a metadata blob: user agent, referrer, language, timezone, screen and viewport size, device pixel ratio, per page timings, a persistent response key, a hashed IP address, and, if you arrived from an invite link, a tester token.

Two things about the questionnaire that are easy to miss and that the page itself already says: your answers are sent to us as you go, so answers you have already given reach us even if you never finish, and one respondent can therefore produce several partial records.

3.8 What we do not collect

• Model provider credentials. We never collect, store or intermediate the credentials or session tokens for a model provider account you sign in to. That sign-in completes through that provider's own flow and never touches us.
• Passwords. Supabase handles authentication.
• Payment card data. There are no payments today.
• The secrets listed in 3.5, which the scrubber removes before upload.
• Where you have used other coding agents. To suggest projects to open, Graphide reads, on your own machine, which folders Claude Code and Codex were used in and when: the working directory recorded at the start of each of their session files, and when each file was last modified. It reads nothing else from those files, no prompt, reply or credential. To tell a suggested project's main language it looks at the names of the files in it, not their contents. All of this stays on your machine and is never sent to us. When you pick a project on Graphide's getting-started page, the diagnostic stream in 3.4 records only where the choice came from (Claude Code, Codex, a recent folder or the folder picker), whether it was one of the suggestions, and its main language, never its path or its name.
• Your IP address is not on this list. See 3.9 below: the product's API does log it.

3.9 IP addresses

The product's API records the IP address your client connects from on each request, in its access log. We use it for two things and nothing else:abuse prevention and rate limiting on the endpoints that accept data without a sign-in, and diagnosing incidents. It is not used to build a profile of you and is not combined with your session content.

It is stored unhashed in that log, which is different from the website: the website stores only a salted hash of the IP for the signup and feedback forms, never the address. Website analytics are a separate case, described in 3.10. Access-log retention is the retention of the host's system journal and is listed in section 7.

3.10 Website analytics

Your theme preference stays in your browser. If you switch between the light and dark themes, the site remembers your choice in local storage under graphide-theme. It stores only lightor dark, so the same theme opens on your next visit. Without a saved choice, the site follows your operating system. Clearing this site's stored data removes the preference.

Every page of graphide.com loads PostHog, a product analytics service, so we can see how the site is used and where people get stuck. It records:

• Page views: the address of each page you open, the page you came from, and when you leave it.
• Clicks on links and buttons, with the element's text and attributes.
• Heatmaps: where on a page you click, move the pointer and scroll.
• Page performance: how quickly each page loads and responds to you, measured as loading time, responsiveness and layout shift.
• Session replay: a recording of your visit that can be played back like a video, showing what was on the screen, where the pointer went, what you clicked and how far you scrolled. Everything you type into a form field is masked before it leaves your browser. Text that is on the page is not: an email address the site shows you while you are signed in appears in the recording. A recording also holds the addresses and timings of the requests the page makes, and the browser's console messages, but not the contents or headers of those requests.
• Your device: browser, operating system, device type, screen size, language and time zone, and an approximate location worked out from your IP address, which PostHog receives because your browser connects to it directly.

It sets a cookie. PostHog keeps a random identifier in a cookie on graphide.com, and in the browser's local storage, so that your visits can be tied together. The site does not tell PostHog who you are: no name, no email address, no account id.

This is not the editor's telemetry and the telemetry settings do not stop it. A content blocker or your browser's tracking protection that blocks PostHog's domains stops it, and clearing this site's cookies and stored data discards the identifier. There is no switch for it on the site itself today.

PLACEHOLDER, counsel to decide the legal basis for website analytics and session replay, and whether visitors from the EU, the EEA and the UK must be asked first. PLACEHOLDER, set and confirm the retention period for events and recordings in the PostHog project, and whether the project discards client IP addresses, then state them in section 7 before publication. None is stated today.

3.11 Screen recording of the editor window

The editor records its own window, and it is on by default. At the full telemetry level, which is the default, Graphide makes a recording of the Graphide window that can be played back like a video: what was on the screen, where the pointer went, what you clicked and how far you scrolled. Part of the window is hidden before anything leaves your machine, and the rest is not. A recording shows:

• The window itself: the title bar, side bar, tabs, panels, menus and status bar, as you see them, including any file, folder or branch name those parts show.
• The canvas, which draws your graph. It includes the names of the files and symbols from your code.
• The chat, which holds your conversations with agents. It shows what you and the agent said, and that can include code.
• Code the chat or the canvas shows, such as the agent's code blocks and the diffs of its edits. Only the code editor's own text is hidden; the same code shown in the chat or the canvas is recorded as it appears.

These are hidden in the editor, before the recording is sent:

• the text of the code editor, which shows as an empty box;
• the terminal;
• anything you type into a field, wherever it is: a prompt you are writing, a search box, the command palette;
• text that looks like a secret, such as an API key or a token.

Views that other extensions you install draw inside the window (their webviews) are never recorded.

Two limits on that. A prompt is hidden while you type it, but once you send it, it is part of the conversation in the chat, and the recording shows it from then on. And secrets are found by their shape, so a secret that does not look like one is not hidden. Hiding text does not make a recording anonymous: the names in the graph, the chat and the window can identify your project and your code.

How it reaches PostHog. The editor does not connect to PostHog. It sends the recording to our API, which does not pass your IP address on and hands the recording to PostHog, the service listed in section 8. Our API's own access log still records the address the recording arrived from, as it does for every request (3.9). A recording carries your install identifier, your account id when you are signed in, the operating system, and the size of your screen and window. It is kept in the same PostHog project as the website analytics in 3.10, and PostHog keeps it for 30 days (section 7).

Video copies. So that we can watch a recording away from PostHog, we may save it as a video on a server of our own that only our own devices can reach, over our private network. That copy is deleted within an hour of PostHog's copy expiring, and never later than 30 days after the recording was made. A request to delete your recordings covers it too. PostHog turns the recording into the video for us, and keeps its own copy of that video for up to 31 days after making it, which can be a little longer than the recording itself.

Only at the full level. At diagnosticand off nothing is recorded, and GRAPHIDE_TELEMETRYand DO_NOT_TRACK, described in section 6, apply to it as they do to the rest of telemetry. Recording starts only from an install whose latest answer to the first run notice was to the version that names screen recording (2026-09-30.2) or a later one, and whose latest answer is full. An install whose latest answer was to an older version records nothing until it has been shown the current notice. Closing the notice without choosing leaves the default, full, in place, and we count that as accepting it. Choosing diagnostic or off stops the recording. Recordings already made stay until they expire.

Pausing. You can pause recording in a window at any time from the Command Palette with Graphide: Pause Session Recording, and start it again with Graphide: Resume Session Recording. The editor does not show an on-screen sign while it records; gr telemetry statusshows the level, and recording happens only at full.

PLACEHOLDER, counsel to decide the legal basis for recording by default, and whether users in the EU, the EEA and the UK must be asked first. See section 5. PLACEHOLDER, owner to decide and counsel to reviewwhether recordings may be used to train models: the paragraph on training in section 4 is written about the session content stream, and this draft does not extend it to recordings. PLACEHOLDER, confirm that we can find and delete one install's recordings in PostHog before their 30 days are up.

4. Why we use it

On training, plainly. By default we may use stored session content, which includes your prompts and your code, to train and improve models. Choosing the diagnostic telemetry level stops session content leaving your machine at all, so it never enters that pool. Content we already hold stays in scope until it is deleted, which is why the deletion paths in section 6 matter.

5. Legal bases, for users in the EU, the EEA and the UK

PLACEHOLDER, counsel to review this whole table, and the consent row in particular. The session content stream is on by default after a notice, which is closer to an opt-out than to the freely given, specific, informed and unambiguous consent the GDPR requires. Counsel decides whether the design has to become opt-in for EU users, whether a different basis applies, or whether the service is not offered there during the beta. This draft states consent because that is what the product's design implies, not because it has been assessed.

PLACEHOLDER, counsel to review the screen recording row in particular. Recording is on by default, and closing the notice without choosing counts as accepting it, which is further from freely given, specific, informed and unambiguous consent than the session content stream is. What is recorded includes conversations and the names of files and symbols, so hiding text (3.11) does not make it anonymous. Counsel decides whether recording has to be opt-in for users in the EU, the EEA and the UK, whether a different basis applies, whether the notice is specific enough, and whether the service is not offered there during the beta.

6. Your controls

Telemetry levels

Three levels, and the middle one is the important one.

Two exceptions at off. First, choosing a level records the choice itself: a single row naming the install, the version of the notice you were shown, the level you picked and the build you picked it in. That row is sent at every level, off included. It exists so we can show that you were asked and what you answered. Second, the usage ping described in 3.4: one event per five minute window in which Graphide was used, carrying your install and account ids and when you were active, never what you did. These two are the only thingsoff sends. Neither carries session content, other diagnostic events or crash reports. If your machine is offline, both are held and sent when the machine next reaches us.

Set it any of these ways. They all write to the same place, so the command line tool and the editor agree:

gr telemetry full | diagnostic | off
gr telemetry status

• In the editor: the setting graphide.telemetry.level.
• For one process: the environment variable GRAPHIDE_TELEMETRY=diagnostic or GRAPHIDE_TELEMETRY=off.
• Machine-wide: the DO_NOT_TRACK environment variable, the same one other developer tools already read. Set it to 1 or true and we turn telemetry off, unlessGRAPHIDE_TELEMETRY is also set, which is specific to Graphide and wins.

Local log files keep being written whatever you choose, because someone asking for help still needs something to hand over. gr logs shows them andgr report packages them, and uploading a report is your act, not an automatic one.

What the levels do not stop: the graph replica upload in 3.2, and sending your content to a model provider when you ask the agent to do something. Sign out to stop the first. Stop using the agent to stop the second.

Deleting things

PLACEHOLDER, counsel to set the deadline for answering a deletion or access request, and the identity check required before we act on one.

7. How long we keep things

Figures below are as of 2026-09-25, except the row for screen recordings of the editor, which is as of 2026-09-29, and the row for video copies of them, which is as of 2026-10-07. Where a window is enforced by code we say so; where it is not, we say that too.

8. Who else receives it

Two caveats we would rather state than have you discover.

1. The recipient list cannot be fully enumerated in advance.OpenRouter chooses an upstream provider at request time. We can tell you the set it has drawn from; we cannot tell you before a request which one will serve it. Every OpenRouter request we make now carries data_collection: deny, which asks OpenRouter to route only to upstreams that do not store the request, and makes a model unavailable rather than silently sending data to one that would. That is a routing instruction to a vendor, not a guarantee we can enforce ourselves.
2. DeepSeek is a PRC based provider and has been reachable through OpenRouter for one model in the catalogue. We hold no agreement with DeepSeek; our relationship is with OpenRouter alone.

PLACEHOLDER, counsel to note that no data processing agreement with any party in this table has been executed or verified.

We will update this table when it changes, and we will note the change under section 13.

9. Where your data goes, geographically

The service is hosted in the United States, on Microsoft Azure. Model providers, Sentry and PostHog are US based. If you are outside the United States, using Graphide means your data is transferred to the United States and processed there.

PLACEHOLDER, counsel to name the transfer mechanism for EU, EEA, UK and Swiss users: Standard Contractual Clauses, the EU-US Data Privacy Framework, or a decision not to offer the service there during the beta. No mechanism is in place today.

10. Children

Graphide is not directed at anyone under 18, and we do not knowingly collect personal information from anyone under 18. If you believe a child has given us personal information, write todan@graphide.com and we will delete it.

PLACEHOLDER, counsel to confirm the age, consistently with the eligibility section of the Terms.

11. Security

An honest paragraph rather than a reassuring one.

Data in transit is protected with TLS, and the API refuses to start if its database or cache connection string does not require TLS, unless the host is the local machine. Your sign-in token is stored in your operating system's keychain where one is available, and where it is not, the daemon falls back to a file with permissions0600 inside a directory with permissions 0700, and prints a warning saying it has done so. Row level security is enabled on every table in the database with no policy granting access to the public API roles, so the shipped anonymous key reaches nothing; the application connects as its own role. A workspace erasure removes the graph replica and the ranking database as well as the database rows, and it removes the sidecar files too, so a later open cannot recover pages of a graph that was supposed to be gone.

What we do not have: a tested backup and restore for the production database; an encrypted at rest guarantee for the per workspace graph replica files, which are ordinary database files protected by directory permissions; a formal security certification of any kind; and any executed data processing agreement with a sub-processor. No method of transmission or storage is completely secure, and we do not promise that ours is.

12. Your rights

If you are in the EU, the EEA or the UK, you have the right to ask for a copy of your personal data, to have it corrected, to have it deleted, to restrict or object to how we use it, to have it ported, and, where we rely on consent, to withdraw that consent at any time. Withdrawing consent does not affect what we did before you withdrew it. You can also complain to your data protection authority.

If you are in California, you have the right to know what we collect and why, to get a copy, to have it deleted, to have it corrected, and not to be treated differently for exercising any of those rights.We do not sell your personal information, and we do not share it for cross context behavioural advertising.

How to exercise any of them: write tohello@graphide.com. Say which right you are exercising. For deletion, the fastest paths for the things you can do yourself are in section 6.

PLACEHOLDER, counsel to specify the response deadline, the identity verification step, and the appeal route required for California.

13. Changes to this policy

We can change this policy. When we do we will post the new version atgraphide.com/privacy with a new effective date, and for a material change we will tell you before it takes effect, by email or in the product.

A change that lengthens how long we keep your content, or that widens what we use it for, applies only to content collected after the change takes effect. It does not reach back to content we already hold. That is why section 7 states no retention limit for session content rather than a long one: a period announced now could not later be lengthened for data collected under it.

14. Contact

Graphide, Inc.
2215 Channing Way, Berkeley, CA 94704, United States
hello@graphide.com