fix: allow PostHog HogQL dollar identifiers - #170
Conversation
|
No actionable comments were generated in the recent review. 🎉 ℹ️ Recent review info⚙️ Run configurationConfiguration used: Organization UI Review profile: ASSERTIVE Plan: Pro Plus Run ID: 📒 Files selected for processing (4)
📝 WalkthroughWalkthroughPostHog command risk parsing now permits literal HogQL dollar identifiers while separately rejecting ChangesPostHog dollar safety
Estimated code review effort: 3 (Moderate) | ~20 minutes Possibly related PRs
Poem
🚥 Pre-merge checks | ✅ 4 | ❌ 1❌ Failed checks (1 warning)
✅ Passed checks (4 passed)
✨ Finishing Touches📝 Generate docstrings
🧪 Generate unit tests (beta)
Comment |
Fixes #169
Root cause
The PostHog command adapter rejected every
$during its generic shell-syntax preflight, before it could establish that the character was JSON data for a canonical nested PostHog read command. A legitimate$pageviewquery therefore becamedestructiveand was blocked by a readonly policy.Change
call <canonical-tool> <JSON object>grammar.$()and${...}.Regression coverage
$pageview+math: daunow classifies asread;$()/${...},$in search/tool names, and destructive nested calls remain blocked.read.execcall, while write calls remain denied.Validation
read, receiveddestructive.npx vitest run tests/posthog-command-wrapper.test.ts tests/risk-classifier.test.ts tests/mcp-wrapper.test.ts -t "PostHog|classifies canonical PostHog command-wrapper reads without weakening command safety"npm test— 85 files passed, 1 skipped; 1,079 tests passed, 23 skipped.npm run lintnpm run typecheckgit diff --checkIndependent security review found no bypass after the JSON-payload scoping refinement.
Summary by CodeRabbit
$pageview, are now recognized as read-only where appropriate.$(...)and${...}, are now blocked in command payloads.