feat(onboarding): create recording policy and targeting-key rule - #69
Open
filipmyllari wants to merge 3 commits into
Open
filipmyllari wants to merge 3 commits into
filipmyllari wants to merge 3 commits into
Conversation
filipmyllari
force-pushed
the
cursor/session-recording-policy-onboarding
branch
from
September 22, 2026 14:42
a136c65 to
9d40d6c
Compare
…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
force-pushed
the
cursor/session-recording-policy-onboarding
branch
from
September 22, 2026 14:55
9d40d6c to
e92ef6b
Compare
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
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>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
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, plusgetContextSchema/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 theirclientslist contains this client's resource name (clients/<id>);listRecordingPoliciesis paginated untilnextPageTokenis empty.The rule is enabled immediately (
enabled: true) because choosing Session Recordings in the wizard is confirmation to start recording. New rules passstableAudiencePercentage: 100andsessionSampleRate: 1. Targeting key is the first entity field on the client schema (typicallyvisitor_id), filled with a persisted identity (localStoragein a browser entrypoint). A reused rule whose audience is"all users"(no segment) is flagged as recording nobody.The SDK
contextuses the same field astargetingKeySelector. Browser code uses the framework's public env var (VITE_,NEXT_PUBLIC_, orREACT_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 inmanualmode 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