Skip to content

feat(onboarding): create recording policy and targeting-key rule - #69

Open
filipmyllari wants to merge 3 commits into
mainfrom
cursor/session-recording-policy-onboarding
Open

filipmyllari wants to merge 3 commits into
mainfrom
cursor/session-recording-policy-onboarding

Conversation

@filipmyllari

@filipmyllari filipmyllari commented Sep 21, 2026 •

Copy link
Copy Markdown
Collaborator

Session-recordings onboarding now creates (or reuses) a Confidence client, a recording policy bound to that client, and an enabled targeting-key rule — not just the client secret and SDK.

The agent uses the recording MCP tools (createClient, listRecordingPolicies, createRecordingPolicy, getRecordingPolicy, addRecordingRule, setRecordingRuleEnabled, plus getContextSchema / addContextField). Client and policy are named after the resolved project directory (so --dir . does not become "."), never the framework. A display-name collision does not reuse another project's client unless it was created earlier in the same run; otherwise the agent retries with a parent-folder or numeric suffix. Policies are reused only when their clients list contains this client's resource name (clients/<id>); listRecordingPolicies is paginated until nextPageToken is empty.

The rule is enabled immediately (enabled: true) because choosing Session Recordings in the wizard is confirmation to start recording. New rules pass stableAudiencePercentage: 100 and sessionSampleRate: 1. Targeting key is the first entity field on the client schema (typically visitor_id), filled with a persisted identity (localStorage in a browser entrypoint). A reused rule whose audience is "all users" (no segment) is flagged as recording nobody.

The SDK context uses the same field as targetingKeySelector. Browser code uses the framework's public env var (VITE_, NEXT_PUBLIC_, or REACT_APP_); the secret is never echoed in STATUS lines, the report, or generated source. If a consent tool is already in the project, recording starts in manual mode after analytics/recording consent; otherwise auto-start is disclosed in the report.

The quickstart report lists policy name and targeting key. Usage lines for rule and consent status are placeholders the agent fills from the actual path. The checklist covers privacy/consent, lowering the production sample rate, and a shared "flag evaluation / recorder context" item. The done-screen change list dedupes agent summary lines (including ✓ prefixes) and asks the agent to list Confidence resources, not only files and packages.

Review follow-ups skipped: recording retention and a claim that masking happens in the browser before upload (Confidence docs/SDK sources did not confirm either).

✔️ Checklist

  • All tests are passing
  • Screenshots attached (for TUI changes)
  • Relevant documentation updated
  • linter/style run on changed files
  • Tests added for new functionality
  • Regression tests added for bug fixes

@filipmyllari
filipmyllari force-pushed the cursor/session-recording-policy-onboarding branch from a136c65 to 9d40d6c Compare September 22, 2026 14:42
…y rule

Session recordings onboarding now creates a client named after the
project, a policy bound to that client's resource name, and an enabled
rule at 100% of visitors with a persisted identity. The done screen
dedupes agent summary lines, and reused segmentless rules are flagged
because they record nobody.

Co-authored-by: Cursor <cursoragent@cursor.com>
@filipmyllari
filipmyllari force-pushed the cursor/session-recording-policy-onboarding branch from 9d40d6c to e92ef6b Compare September 22, 2026 14:55
The requirement to report the recording policy and rule lived in the
recording step, far from where the agent writes its closing summary, so
those resources were missing from the TUI change list even when they
were created. State it in the summary step instead, and reuse wording
prescribed earlier so a change is not listed twice.

Co-authored-by: Cursor <cursoragent@cursor.com>
@filipmyllari
filipmyllari marked this pull request as ready for review September 22, 2026 15:38
Resolve project names so --dir . cannot create a client called ".",
and do not reuse another project's client on a display-name collision.
Gate recording behind an existing consent tool, use the framework's
public env var in browser code, and let the report fill the actual
rule and consent status.

Co-authored-by: Cursor <cursoragent@cursor.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant