How we handle your data

What the upload script collects

AI coding agent transcripts

Claude Code — JSONL files from ~/.claude/projects/. The Docker container reads these locally to generate narratives and extract behavioral signals. Only the processed output leaves your machine: per-session narratives (~2,000 characters each), bounded tool-use summaries (session_events — file paths + truncated command text + action types, capped at ~3,000 events per session with text fields shortened within each event), a 200-character excerpt of your first prompt for each session, user-highlight excerpts (representative quotes drawn from your prompts, capped at 10,000 characters per session), steering traces (counts and timestamps of course-corrections), and dispatch metadata for subagent tasks (task descriptions ≤200 characters, passed through the credential redactor). Raw conversation history, full prompts, full agent responses, and full tool outputs do not leave your machine.

Cursor IDE — extracted from ~/Library/Application Support/Cursor (macOS) or the equivalent on Linux/Windows, and merged into the same pipeline.

Codex CLI — JSONL files from ~/.codex/sessions, uploaded and analyzed alongside Claude Code sessions.

Cursor IDE and Codex CLI sessions are restricted to sessions whose git remote matches the selected project, unless you pass --all.

Git repository data (unless --no-repo)

Your source code, file contents, and diffs stay on your machine. The Docker container mounts your repo read-only for on-device code quality analysis; only aggregate metrics (file counts, language ratios, complexity scores) are uploaded.

The following git metadata is uploaded to the server: per-author numstat totals (insertions/deletions per commit), velocity signals (commits/day, LOC/day, active days), commit metadata for up to ~1,000 recent commits (sha, short sha, author name, author email, date, subject — no diffs, no file contents), and your git remote URL. Use --no-repo to skip all repo analysis entirely.

Metadata sidecar

Git remote URLs, local directory paths, and PR links extracted from transcripts.

What the script removes before sending

Paxel applies these redaction patterns to all content destined for upload (decision text, session events, narratives, first-prompt excerpts, user-highlight quotes, and commit subjects) inside the Docker container, before any data leaves your machine — both at the source as each field is extracted and again, fail-closed, at the upload boundary. The same patterns also run server-side on persisted LLM payloads as defense-in-depth:

Excluded from code quality analysis

The on-device code quality analyzer skips: node_modules vendor .git build dist tmp log

How to limit what you send

Account data

What we generate from your data

• LLM narratives. High-level behavioral summaries of each session, generated by Anthropic's Claude or OpenAI's GPT models (Paxel's analysis models, routed through a proxy).
• Behavior scores. Numeric scores across 5 axes: Execution Leverage, Steering, Engineering Quality, Product Thinking, Planning.
• Decision patterns. Structured records of how you directed the AI during coding sessions.
• Most-questionable-prompts surface. For each upload, an LLM picks up to 3 of your decision-text user directives that read as vague or scoped-too-loosely and writes a short one-line reason per pick. Stored as {prompt, reason} pairs on the upload row and shown on your profile page under "Your most questionable prompts". Subject to the same admin-access and retention rules as your other upload data.
• Subagent dispatch metadata. When you run Claude Code's Task or Agent tool to spawn a subagent, we record counts of dispatches, returns, the subagent's run_in_background flag, and a short dispatch description (≤200 chars, passed through the same redactor as decision text to strip code identifiers and file paths). The raw dispatch prompt is never uploaded — only the first 12 hex characters of its SHA-1 hash, used as a fallback identifier for matching subagent sessions to their parent when the parent session was filtered out upstream.
• Evidence excerpts. Transcript and commit excerpts with vector embeddings, used for search and analysis.
• Episode groupings. Sessions grouped into coherent work episodes.
• Commit group analysis. Git diffs grouped and reviewed by LLM for code quality signals.
• LLM call logs. Every LLM call Paxel makes — on behalf of your upload (via the client proxy) and for internal system tasks — is recorded on Postgres. Prompts, responses, and row metadata (model, token counts, cost, HMAC nonce, timestamps) all live on the same table. Retention schedule is in Section 10.
• Upload error messages. When an upload fails, we store the normalized exception message and — for LLM proxy errors whose response body was not our usual JSON envelope (e.g. an infrastructure-layer "Forbidden" response) — a scrubbed preview of that response body. Total stored length is capped at 500 characters. Scrubbing removes Anthropic/OpenAI API keys, GitHub tokens, Bearer tokens, YC tokens, JWTs, email addresses, and IPv4 addresses before storage. These error messages are visible to you on your results page and to YC admins.

Third-party services

Who can see your results

Security

• HTTPS with HSTS enforced on all connections
• Secure, HttpOnly, SameSite cookies
• API tokens and magic link tokens SHA256-hashed at rest
• Rate limiting: 100 requests/hour per IP, 500 LLM calls/day per token
• Sensitive parameters filtered from server logs
• CORS restricted to application origin
• Anti-gaming: 5-layer verification system (HMAC nonces, score re-derivation, anomaly detection)

What we do not collect

• No source code files, working-tree snapshots, or git archive tarballs
• No per-commit diffs or patch content
• No raw transcript JSONL — we upload narratives and bounded-length session events, not the original conversation history
• No analytics services (no Google Analytics, Mixpanel, Segment, Hotjar)
• No tracking pixels or beacons
• No browser fingerprinting
• No cookies beyond the session cookie
• No third-party ad or marketing trackers
• localStorage is used client-side only (chat UI state)

Data retention and deletion

Contact

Questions about privacy or data handling: oss@ycombinator.com

Example: what gets uploaded to YC

Anonymized example of the JSON payload sent from the Docker container. No source code, no file contents, no raw transcripts.

{
  "episode_scores": [
    {
      "title": "Authentication refactor",
      "scores": { "throughput": 7.5, "steering": 8.0, "eng_quality": 7.0, "product_thinking": 6.5, "planning": 7.0 },
      "confidence": "high"
    }
  ],
  "session_summaries": {
    "abc123": "Developer refactored auth middleware across 3 sessions. Started with a clear plan, tested edge cases, caught a regression early..."
  },
  "session_metadata": [
    { "session_id": "abc123", "started_at": "2026-04-15T09:12:03Z", "duration_minutes": 47, "project": "acme" }
  ],
  "git_remote": "git@github.com:acme/service.git",
  "recent_commits": [
    { "sha": "a1b2c3def4567890", "short": "a1b2c3d", "author": "Avery Builder", "email": "avery@acme.example", "date": "2026-04-15T09:12:03Z", "subject": "Refactor auth middleware" }
  ],
  "decisions": [
    { "title": "Chose JWT over session cookies", "rationale": "Rejected session cookies because the app is stateless. [identifier] handles refresh; [path] stores the decision log." }
  ],
  "git_metrics": {
    "velocity": { "loc_per_day": 3200, "commits_per_day": 12 },
    "total_commits": 47,
    "loc_stats": { "test_ratio": 1.2 }
  },
  "client_telemetry": {
    "pipeline_duration_s": 612,
    "llm_stats": { "total_calls": 84, "total_cost_cents": 31 },
    "system_info": { "ruby_version": "3.4.8", "rails_env": "production", "pid": 4321 }
  },
  "nonces": ["req_001:a1b2c3d4", "req_002:e5f6g7h8"]
}