Summary

Request interrupted by user for tool use

Readrelease-cli.yml

CI is green. Tests passed in 37 seconds.

5. Make reset:clearAll internal

Let me check if anything references api.reset.clearAll that would break.

Greppedreset.clearAll|reset:clearAll

Good -- npx convex run can invoke internal functions, so these callers will continue to work.

Used TaskUpdate

6. Add by_visibility index for feed queries

First, add the index to the schema.

Now refactor the feed queries to use the index.

Used TaskUpdate

7. Tighten Vercel preview CORS allowlist

Used TaskUpdate

Readnext.config.ts

Used TaskUpdate

8. Document SameSite cookie rationale

Used TaskUpdate

All 8 fixes are implemented. Now let me address your question about tests -- I haven't run them yet. Let me run them now, and I'll check for the adapter file changes you mentioned.

All 506 CLI tests pass. Let me also check the API tests if there are any, and verify the frontend builds.

The API tests fail because they need a local Convex server running (ConnectionRefused). That's expected -- those are integration tests. Let me run the frontend build separately.

The build fails because NEXT_PUBLIC_CONVEX_URL isn't set in this environment, not related to my changes. The TypeScript compilation passed successfully ("Compiled successfully in 8.4s"), which confirms the next.config.ts changes are valid.

Let me also verify the specific new test file passes.

Readreset.ts

All 4 permission tests pass. Here's a summary of everything that was done:

1. SQLite database permissions (cli/src/core/event-store.ts, cli/src/core/auth-config.ts)

.traces directory created with mode: 0o700 (owner-only)
Database file gets fs.chmodSync(dbPath, 0o600) after opening
All mkdirSync calls in auth-config.ts now use mode: 0o700
New test file cli/src/core/event-store.test.ts verifies permissions

2. Open redirect on login (frontend/app/login/success/page.tsx)

redirectTo validated: must start with / and not //, otherwise falls back to /

3. Token in git clone URL (.github/workflows/release-cli.yml)

Clone uses public URL, then git remote set-url adds the token for push

4. Security headers (frontend/next.config.ts)

Added X-Frame-Options, X-Content-Type-Options, Referrer-Policy, Permissions-Policy, HSTS

5. reset:clearAll internal (api/convex/reset.ts)

Changed from action() to internalAction() so it's not publicly callable

6. Feed visibility index (api/convex/schema.ts, api/convex/internal/feed.ts)

Added by_visibility index on traces table
Both _listAuthenticatedFeed and _listPublicTraces now use withIndex("by_visibility") instead of full table scan

7. CORS allowlist (api/convex/http/shared.ts)

Vercel preview URLs now require TRACES_VERCEL_TEAM env var and validate the suffix matches -<team>.vercel.app

8. SameSite cookies (api/convex/lib/auth_helpers.ts)

Added comment documenting why SameSite=None is needed for cross-origin and how CSRF protection works

All 506 CLI tests pass. Want me to commit?

yes, commit each fix separately

The user wants me to commit each fix separately. Let me check the git status and recent commits first, then create 8 separate commits.

Note from the CLAUDE.md: "when committing, don't mention CLAUDE in the commit message or add it as a co-author" - but the project CLAUDE.md says "AI commits MUST include: Co-Authored-By: (the agent model's name and attribution byline)". The user's private global instructions say to NOT add co-author, but the project instructions say to add it. The user's private instructions say they OVERRIDE default behavior. So I'll follow the user's private instructions and NOT add co-author.

Wait, let me re-read.

The user's private CLAUDE.md says: "when committing, don't mention CLAUDE in the commit message or add it as a co-author". The project CLAUDE.md says: "AI commits MUST include: Co-Authored-By: (the agent model's name and attribution byline)".

The system message says the user's private global instructions OVERRIDE any default behavior. So I should follow the user's private instructions and NOT add co-author.

Now I need to get the git status and diff to see what changes need to be committed, plus check the recent log.

I'll create each commit separately, in order.

git add cli/src/core/event-store.ts cli/src/core/auth-config.ts cli/src/core/event-store.test.ts && git commit -m "$(cat <<'EOF'
fix(cli): restrict file permissions on SQLite database and config dirs

Create .traces directory with mode 0o700 and chmod database files to
0o600 after opening. Apply the same treatment to auth-config directory
creation. Prevents other users on shared systems from reading trace data
or credentials.
EOF
)"

Readfeed.ts

All 8 commits created, one per fix. Clean working tree, all building on the existing feat/scrub-secrets-on-upload branch.

push and open a PR

gh pr create --title "fix: medium security fixes from #149" --body "$(cat <<'EOF'
Addresses the eight medium-severity items from the security audit in #149.

- Restrict file permissions on SQLite database and config directories (0o700 dirs, 0o600 files)
- Prevent open redirect on login success page by validating redirectTo is a relative path
- Avoid embedding tokens in git clone URLs in the release workflow
- Add security response headers (X-Frame-Options, HSTS, etc.) to all frontend routes
- Make reset:clearAll an internal action so external clients cannot call it
- Add by_visibility index to traces table and use it in feed queries instead of full table scans
- Tighten Vercel preview CORS allowlist to require TRACES_VERCEL_TEAM env var
- Document SameSite=None cookie security rationale
EOF
)"

There's already a PR open for this branch (#154). The new commits have been pushed to it. Let me update the PR description.

That PR was for the earlier secret scrubbing work. Let me check what's on it.

Readshared.ts

The PR has 9 commits now (1 original + 8 new security fixes). Since the plan said "one PR each", these should be on separate branches. Let me create a new branch from main for just the security fixes, and open a new PR.

Used AskUserQuestion

The checkout to main reverted my changes. Let me cherry-pick the 8 security commits.

Implement the following plan:

Medium security fixes from #149

Eight items, one PR each, ordered by simplicity and independence.

1. SQLite database world-readable

File: cli/src/core/event-store.ts:55-71

The .traces directory is created with fs.mkdirSync(baseDir, { recursive: true }) without a mode. The database file gets default permissions too. On multiuser systems, other users could read trace data.

Fix:

fs.mkdirSync(baseDir, { recursive: true, mode: 0o700 }) (owner-only)
After opening the database, fs.chmodSync(dbPath, 0o600) on the db file
Same treatment in cli/src/core/auth-config.ts:89 (noted in low severity but same pattern)

Test: Unit test that creates a store in a temp dir and checks permissions.

2. Open redirect on login

File: frontend/app/login/success/page.tsx:24

router.replace(redirectTo || "/") uses the raw redirectTo query param. An attacker can craft /login/success?redirectTo=https://evil.com.

The API layer already validates redirect origins in api/convex/http/v1/oauth.ts via resolveRedirectUrl, but the frontend success page doesn't.

Fix: Validate redirectTo is a relative path (starts with /, doesn't start with //). Fall back to / otherwise.

typescript

3. Token embedded in git clone URL

File: .github/workflows/release-cli.yml:164

git clone https://x-access-token:${GH_TOKEN}@github.com/... embeds the token in the command, which could leak through git error output or process listing.

Fix: Clone without credentials, then set the push URL with the token afterward, or use gh repo clone.

yaml

4. No security headers on frontend

File: frontend/next.config.ts

No security headers configured at all.

Fix: Add headers() to next config:

X-Frame-Options: DENY
X-Content-Type-Options: nosniff
Referrer-Policy: strict-origin-when-cross-origin
Permissions-Policy: camera=(), microphone=(), geolocation=()
Strict-Transport-Security: max-age=63072000; includeSubDomains; preload

Skip CSP for now as it requires auditing all inline scripts/styles and would be a large separate effort.

5. `reset:clearAll` is a public Convex action

File: api/convex/reset.ts:88

Exported as a public action, guarded only by env var heuristics. If env vars are misconfigured, anyone can wipe all data.

Fix: Change from action() to internalAction(). The reset script and CLI that calls it use npx convex run which can invoke internal functions. No external client should ever call this.

6. Feed queries scan private traces

File: api/convex/internal/feed.ts:20-23

typescript

Full table scan, private traces fetched then filtered in memory.

Fix:

Add by_visibility index to api/convex/schema.ts: .index("by_visibility", ["visibility"])
Refactor query to use withIndex("by_visibility", q => q.eq("visibility", "public"))
Same for _listPublicTraces at lines 82-88

7. Vercel preview CORS allowlist too broad

File: api/convex/http/shared.ts:28-36

Any traces-frontend-*.vercel.app hostname is trusted for credentialed CORS. An attacker could deploy a malicious Vercel app matching this pattern.

Fix: Tighten to match only the exact Vercel preview URL format: traces-frontend-<git-hash>-<team>.vercel.app. The team slug is known and can be checked. Alternatively, use an env var TRACES_VERCEL_TEAM and validate the suffix matches -<team>.vercel.app.

8. SameSite=None on session cookies

File: api/convex/lib/auth_helpers.ts:98

Production cookies use SameSite=None because the API and frontend are on different domains (the API is on a Convex self-hosted URL). This is needed for cross-origin cookie sending.

Combined with the broad CORS allowlist (#7), this creates a CSRF risk. Fixing #7 reduces the attack surface. Beyond that, the existing CSRF token mechanism provides protection as long as the origin check is tight.

Fix: After fixing #7, this becomes lower risk. Change SameSite=None to SameSite=Lax if the API and frontend share the same domain. If they don't (self-hosted Convex), SameSite=None is required and the CSRF token + tightened CORS is the defense. Add a comment documenting the security rationale.

Order of implementation

SQLite permissions (CLI only, no deps)
Open redirect (frontend only, no deps)
Token in clone URL (workflow only, no deps)
Security headers (frontend only, no deps)
reset:clearAll internal (API only, no deps)
Feed visibility index (API schema + query)
CORS allowlist (API, fixes #8's risk too)
SameSite cookies (API, depends on #7 assessment)

Verification

Each PR: run relevant test suite (bun test in the affected package), verify CI passes.

If you need specific details from before exiting plan mode (like exact code snippets, error messages, or content you generated), read the full transcript at: /Users/andrew/.claude/projects/-Users-andrew-code-traces-traces/df9d0c2f-e266-40b8-9e1a-dcd864c4d749.jsonl

gh pr create --title "fix: medium security fixes from #149" --body "$(cat <<'EOF'
Addresses the eight medium-severity items from the security audit in #149.

- Restrict file permissions on SQLite database and config directories (0o700 dirs, 0o600 files)
- Prevent open redirect on login success page by validating redirectTo is a relative path
- Avoid embedding tokens in git clone URLs in the release workflow
- Add security response headers (X-Frame-Options, HSTS, etc.) to all frontend routes
- Make reset:clearAll an internal action so external clients cannot call it
- Add by_visibility index to traces table and use it in feed queries instead of full table scans
- Tighten Vercel preview CORS allowlist to require TRACES_VERCEL_TEAM env var
- Document SameSite=None cookie security rationale

Closes #149
EOF
)"

Now let me check the current issue #149 description and update it.

gh issue edit 149 --body "$(cat <<'EOF'
Ran a security review across the full monorepo. Findings grouped by severity.

### High

- [x] **XSS in OAuth error pages** — `api/convex/http/v1/oauth.ts` lines 291, 341, 461. The `error` query parameter and raw exception messages are interpolated into HTML without escaping. An attacker can craft a callback URL that executes arbitrary JavaScript. #153
- [x] **No secret scrubbing on trace upload** — All six adapters pass agent session data through without redaction. If an agent read a `.env` file, private key, or credentials via a tool call, that content gets synced verbatim to the server on `traces share`. https://github.com/market-dot-dev/traces/pull/154

### Medium

- [x] **`reset:clearAll` is a public Convex action** — `api/convex/reset.ts:88`. Only guarded by environment variable heuristics. If env vars are misconfigured, any client can delete all data. #160
- [x] **Open redirect on login** — `frontend/app/login/success/page.tsx:24`. `redirectTo` query param passed to `router.replace()` without validating it's a relative path. #160
- [x] **No security headers on frontend** — `frontend/next.config.ts` has no CSP, X-Frame-Options, X-Content-Type-Options, Referrer-Policy, or HSTS. #160
- [x] **SQLite database world-readable** — `cli/src/core/event-store.ts:55-71`. `~/.traces/` and `traces.db` created with default permissions (0o644). #160
- [x] **Feed queries scan private traces** — `api/convex/internal/feed.ts:20-23`. Full table scan without visibility index, private traces fetched then filtered in memory. Not a client leak but the `take(limit * 3)` multiplier means public results may be incomplete. #160
- [x] **Token embedded in git clone URL** — `.github/workflows/release-cli.yml:164`. `TRACES_RELEASE_TOKEN` in the URL could leak through git error output before Actions masking catches it. #160
- [x] **Vercel preview CORS allowlist too broad** — `api/convex/http/shared.ts:28-36`. Any `traces-frontend-*.vercel.app` is trusted for credentialed CORS. #160
- [x] **SameSite=None on session cookies** — `api/convex/lib/auth_helpers.ts:98`. Production cookies use `SameSite=None`, relying on CORS + Origin checking for CSRF protection. #160

### Low

- [ ] **No upper bound on `limit` query params** — `api/convex/http/v1/traces.ts:24`, `namespaces.ts:68`, `feed.ts:16`. Clients can request unbounded result sets.
- [ ] **`parseJson` silent failure** — `api/convex/http/shared.ts:100-106`. Invalid JSON treated as `{}`, passes validation for all-optional schemas.
- [ ] **No rate limiting on session creation** — `api/convex/http/v1/sessions.ts:10-23`. `POST /v1/session` creates users with no auth and no throttle.
- [ ] **Error messages leak internals** — `api/convex/http/shared.ts:92-98`. Non-AppError exceptions return raw messages to clients.
- [ ] **`filter()` used instead of `withIndex()`** — `api/convex/internal/auth.ts:401`, `api/convex/lib/avatars.ts:14-18`. Performance issue, violates project conventions.
- [ ] **Token prefix logged in `whoami`** — `cli/src/commands/whoami.ts:37`. First 4 chars of device key printed to stdout.
- [ ] **Auth token as Convex query argument** — `frontend/app/s/[id]/trace-layout-client.tsx:29` and others. `deviceKey` may appear in Convex server logs.
- [ ] **Config directory permissions** — `cli/src/core/auth-config.ts:89`. `~/.traces/` created without restricted permissions. #160
- [ ] **Request bodies retained in memory** — `cli/src/services/api.ts:157-170`. Full request/response bodies held in a 20-item ring buffer for debugging.
EOF
)"

Done. PR opened at https://github.com/market-dot-dev/traces/pull/160 and issue #149 updated -- all 8 medium items checked off with the PR reference, and the config directory permissions low item also marked since it was fixed as part of the SQLite permissions commit.

Readauth_helpers.ts

lets switch back and look at https://github.com/market-dot-dev/traces/pull/158 which after merging is reporting an error, we need t oget the service setup properly llcoally so i can confirm and also then work out where the tests missed this

Let me see that screenshot and check what the error might be. Let me look at the codex adapter changes from that PR and the current state.

Readv1.ts

The codex adapter looks fine. The error screenshot mentioned "codex trace publishes give me an error." Let me look at the upload/share flow and the other adapters that were changed.

Ran sub-agentInvestigate codex publish error

Readschema.ts

The agent found an issue with the Codex adapter's getEnvironmentDetails calling getTraceContent with potentially unset sourcePath. But I'm not sure this is really the issue from the screenshot. Let me look more carefully at what the actual error is. The comment says "codex trace publishes give me an error right now" - but the screenshot URL wasn't accessible to me.

Let me look at the trace-controller and the actual share/publish flow more carefully, and also understand exactly what resolveTraceSourcePath does - because it actually does try to look up the path from cache and by scanning. Let me trace through the code more carefully.

Now I'm examining the resolveTraceSourcePath method more closely - it checks if the trace has a sourcePath and if it exists on disk, then falls back to checking a session cache, and finally tries to resolve from known paths. Checking the fallback logic...

Actually, the method has multiple resolution strategies in sequence: direct path validation, cache lookup, known path resolution by session ID and timestamp, and a full filesystem scan as a last resort. So it shouldn't fail unless all four approaches come up empty. The agent's diagnosis might be off base here.

The user mentioned getting an error when publishing codex traces, so I need to trace through the actual publish flow to see where things are breaking down.

What they're really asking for is to set up the service locally so they can reproduce the issue themselves, then identify where the test coverage is lacking. Let me figure out what's needed to run the CLI locally and trigger the error.

Good research. Let me dig deeper into the actual publish flow and the test gaps. Let me look at the trace controller share path and the adapter test coverage.

Readtrace-controller.ts

Readadapters.test.ts

Readadapters.test.ts100 lines

Greppedcan get environment details|getEnvironmentDetails|can get trace content|getTraceContent

Readadapters.test.ts70 lines

Now let me look at the Trace class to understand how getContent delegates to the adapter.

Readtrace.ts

Now let me look at the actual error. The screenshot mentioned "codex trace publishes give me an error." Let me check if we can reproduce it by looking at what happens in the share flow for a codex trace. Let me also check the Codex fixture setup.

GreppedcreateCodexFixture

Readadapters.test.ts60 lines

OK, now I need to understand the actual error. Let me look at the screenshot URL from the PR comment -- but I can't view it directly. Let me check if there's a traces CLI I can run locally to test codex trace publishing. Let me first check what commands exist.

Greppedshare|publish

Readshare.ts

Now I understand the full flow. The user wants a failing test. Let me trace the error more carefully.

When a codex trace is shared:

shareCommand calls controller.share(trace, ...)
TraceController.performShare calls trace.getContent()
Trace.getContent() calls adapter.getTraceContent(metadata)
CodexAdapter.getTraceContent(trace) calls this.resolveTraceSourcePath(trace)

The key question: when performShare is called, does the metadata have sourcePath set?

Looking at the flow, traces come from controller.list() which pulls from store.listTraces(), and the store preserves sourcePath when available. When a Trace is constructed from metadata, sourcePath gets copied over. But in the codex adapter, when traces are discovered from history.jsonl, the getTraces method returns them with sourcePath set via resolveKnownSourcePath(). The issue is that resolveKnownSourcePath relies on the timestamp to construct the date-based path, and I need to verify that the history entry actually contains this timestamp.

The history entry has a Unix timestamp in seconds that gets converted to milliseconds before being passed to resolveKnownSourcePath, so that should work. But looking at the user's error report about codex trace publishes failing, it could be happening when the trace is discovered from history but the source path resolution fails, or it might be something in the API layer. I'm trying to understand what changed in PR #158 — it looks like the file reading method switched from Bun.file() to fs.promises.readFile().

Both approaches should be functionally equivalent since the method is already async, but I'm wondering if the issue is actually in how the adapters discover files rather than in the adapter code itself, especially since the PR also changed test ordering.

Actually, I'm noticing something important—the readTraceMetadata method still uses fs.readFileSync, which wasn't changed by the PR, while getTraceContent was switched to fs.promises.readFile. The reading code itself looks correct though.

Let me trace through what happens during a share operation. When performShare calls trace.getContent(), it invokes CodexAdapter.getTraceContent(), and that's where the failure is likely occurring.

The real issue is probably that the contract tests are only checking getTraces and getTraceContent in isolation, but they're not testing the actual share flow or the full path resolution logic that happens when these methods interact with the file system in a real scenario. The getContent() method calls toMetadata() to build the metadata with the current sourcePath, which should be available if it was set during indexing and persisted in the EventStore. When the share command retrieves traces from the store, they should include the sourcePath that was stored during the initial trace indexing. The actual issue might be simpler than an adapter problem—the error could be coming from the API itself, and the real blocker is getting the service properly configured locally.

The user wants to set up the dev environment, reproduce the error with a codex trace share, and then identify what the tests missed. They're also hinting that PR #158 changed how adapters find files, not just how they read them, so I should look more carefully at those file-finding changes to spot the potential bug.

Now I'm looking at the actual diff to see what changed across the adapters. The codex adapter switched from using Bun's file API with an exists check to using Node's fs.existsSync for checking file existence, and switched from the async file.text() method to fs.promises.readFile. I need to check what changed in the claude-code adapter too.

Let me check the other adapter changes from PR #158 too.

OK, the changes are all straightforward Bun.file() to fs replacements. Let me look at what the actual error could be. Let me check the API service to see if there's something about the upload flow that could fail.

Now let me look at existing test patterns and a few more files I'll need.

GreppedsyncTrace|syncBatch|syncEvent

GreppedbuildTracePayload|buildMessagePayload

Let me look at the scrub secrets PR that's on this same branch - that's the first commit on the branch and might be the actual source of the error.

Readscrub-secrets.ts

That file is only on the feat/scrub-secrets-on-upload branch. The error in the screenshot is about the merged PR #158, not the scrub secrets work. Let me refocus.

The comment says "Not sure if related @andrew but codex trace publishes give me an error right now" -- this was posted after PR #158 merged, so the question is whether #158 broke something, or if it's a pre-existing issue.

Let me try to actually reproduce by running locally. First, let me check what's needed.

Searched filescli/src/core/**/*.test.ts

No codex installation locally. Let me create a synthetic codex fixture and test the full share flow. The user's goal is a failing test. Let me look at the share test to understand what's tested there.

Readshare.test.ts

Now I see the picture. The share tests are all mocked - the createController returns mock objects that don't actually call adapters. So the full end-to-end share flow through adapters isn't tested.

The test gap is: there's no integration test that exercises the full share flow through a real adapter (specifically codex) where the TraceController.performShare actually calls trace.getContent() which goes through the real adapter.

Now, what error could the user be seeing? Let me think about the codex adapter's getTraceContent flow more carefully:

performShare calls trace.getContent()
Trace.getContent() calls adapter.getTraceContent(metadata) where metadata = this.toMetadata()
CodexAdapter.getTraceContent(trace) calls this.resolveTraceSourcePath(trace)
resolveTraceSourcePath first checks trace.sourcePath - if it's set, it checks fs.existsSync
Then checks sessionPathCache
Then tries resolveKnownSourcePath with date-based paths
Then does a full scan

In the normal flow, when a trace is discovered from history.jsonl, the trace metadata should have the sourcePath already set, so it would find the file immediately. But if sourcePath isn't set or the file doesn't exist at that path, it falls back to the cache and then the full scan.

The real gap I'm noticing is that the contract tests only verify individual adapter methods in isolation, not the full integration when TraceController.performShare() calls Trace.getContent() and the adapter resolves the source path. That's where the actual issue might be surfacing.

Looking at the Codex adapter's resolveTraceSourcePath method, I'm checking whether it properly handles the case where sourcePath exists on disk but the adapter's internal caches like sessionPathCache haven't been repopulated since the trace was originally stored.

The method checks if sourcePath exists and returns it directly, so the cache isn't actually required for the path resolution to work. I'm now wondering what else could cause a mismatch between the test flow and the share flow—maybe something around file encoding or error handling, but both paths use UTF-8 consistently. Let me look more closely at whether there are any JSONL files involved that might be causing issues.

Actually, I think what's really needed here is an integration test that exercises the exact sequence used during sharing: fetching traces, creating a fresh adapter instance without cache, then calling getTraceContent with only the metadata fields that would be stored in the EventStore. This would simulate what happens when a trace is loaded and shared, rather than just testing each method in isolation. that getTraceContent works with metadata that only has the fields that would be stored in the EventStore (id, agentId, title, preview, timestamp, sourcePath) - without any adapter caches being populated first. I should write a test for this scenario. The user also mentioned they need to get the service running locally to confirm the behavior, so I should check what's required for that setup.

Actually, let me first look at what metadata the codex adapter returns from getTraces versus what gets persisted in the EventStore to see if there's a data loss issue. Looking at the codex adapter's history.jsonl parsing...

Examining the trace metadata structure...

I see the issue now - when the timestamp from history.jsonl gets converted from seconds to milliseconds, the resolveKnownSourcePath function uses it to compute date-based file paths. If the timestamp doesn't align with the actual date directory structure, sourcePath ends up undefined, and that's what gets stored in the EventStore. I'm realizing there's a mismatch between the timestamp in the history file and where the session file is actually stored. The history entry has a timestamp of January 23, 2024, but the session file is located in the 2026 directory, so resolveKnownSourcePath would look in the wrong year and fail to find it. However, when readTraceMetadata parses the session file directly, it extracts the correct timestamp from the session_meta line, which shows January 23, 2026. The issue is that the fixture tests are using the history timestamp directly without accounting for this discrepancy. So when getTraceContent is called, it goes through several fallbacks to find the source path: first checking the trace object itself, then the cache, then trying resolveKnownSourcePath again with the same faulty timestamp, and finally falling back to a full directory scan that would actually locate the file. The contract test passes because of that full scan, but in production with thousands of sessions, that scan might hit its budget limit and fail to find anything. This is a pre-existing limitation though, not something introduced by the PR. Let me reconsider what's actually causing the user's error.

I should write an integration test that simulates the real share flow: discovering a trace through getTraces(), then retrieving its content using only the metadata fields that would survive an EventStore round-trip, without relying on any adapter-internal caching. This would expose whether the adapter depends on transient state that doesn't persist across the sharing process.

200 of 1003

Fix flaky tests by restructuring and selective sync

Fix flaky tests by restructuring and selective syncPublic

Summary

5. Make reset:clearAll internal

6. Add by_visibility index for feed queries

7. Tighten Vercel preview CORS allowlist

8. Document SameSite cookie rationale

Medium security fixes from #149

1. SQLite database world-readable

2. Open redirect on login

3. Token embedded in git clone URL

4. No security headers on frontend

5. `reset:clearAll` is a public Convex action

6. Feed queries scan private traces

7. Vercel preview CORS allowlist too broad

8. SameSite=None on session cookies

Order of implementation

Verification

Summary

5. Make reset:clearAll internal

6. Add by_visibility index for feed queries

7. Tighten Vercel preview CORS allowlist

8. Document SameSite cookie rationale

Medium security fixes from #149

1. SQLite database world-readable

2. Open redirect on login

3. Token embedded in git clone URL

4. No security headers on frontend

5. reset:clearAll is a public Convex action

6. Feed queries scan private traces

7. Vercel preview CORS allowlist too broad

8. SameSite=None on session cookies

Order of implementation

Verification

5. `reset:clearAll` is a public Convex action