feat(cli): add feedback add and delete commands for quick CLI feedback

[kanadgupta]

What

Adds a TS-only supabase feedback command family (from the original brainstorm) so users — and agents — can send quick, low-friction feedback to the Supabase team without filing a GitHub issue, and revoke a submission later (e.g. an accidentally pasted secret):

supabase feedback add "when I run multiple stacks in parallel I get port conflicts"
# → Thanks for the feedback!
# → To delete this feedback later, run: supabase feedback delete <token>

supabase feedback delete 123e4567-e89b-12d3-a456-426614174000

Part of CLI-1946; the delete command is CLI-2188. Scope evolved in this thread: feedback add (no btw alias) plus a token-based delete path, rather than full user-scoped CRUD.

How feedback add works

• Message resolution: positional args → piped stdin (non-TTY) → interactive prompt (TTY, text mode) → error. Messages starting with a dash use the -- sentinel. Piped stdin is read in constant memory with a 64 KB cap; a read error mid-pipe discards the partial buffer rather than submitting a truncated message. Messages over the 1000-character limit are rejected client-side (counted in code points, matching Postgres char_length).
• Transport: submits through the SECURITY DEFINER RPC submit_interfaces_feedback (feat: table for collecting interfaces feedback supabase#48420) via supabase-js — the table has no insert grant, so the RPC is the only door and the delete token is always server-generated. The committed keys are publishable (anon) keys, safe to ship in the binary. 10s timeout.
• Delete token: the RPC returns a uuid delete_token exactly once. Text mode prints it with a "to delete this later" hint (including --project-ref <ref> when the submission carried one, since the row can only be deleted with that ref presented); json/stream-json carry it as delete_token in the result payload. The CLI never persists it.
• Submission context: CLI version, user agent, OS/arch, agent detection (is_agent/agent_name via @vercel/detect-agent, to support the activation analysis in AI-961), and the linked project ref. metadata.source: "cli" distinguishes CLI rows from the future MCP path. The access token is never sent. The persisted gotrue user id (distinct_id in telemetry.json, stamped at login) is sent as user_id only when the user is logged in and telemetry consent is granted — best-effort attribution; logged-out or opted-out runs omit it. A row submitted with a user_id can only be deleted by the same account.
• Project ref resolution: SUPABASE_PROJECT_ID → <workdir>/supabase/.temp/project-ref (the file supabase link writes) → omitted. A malformed SUPABASE_PROJECT_ID fails with the shared invalid-ref error, like every other command's explicit ref. The file is read directly (not via ProjectRefResolver, whose prompt path needs the platform API) so feedback works logged-out; a broken or malformed ref file degrades to "unlinked".
• Environments: the feedback backend follows the resolved profile the same way the Management API URL does. supabase-staging/supabase-local post to the persistent staging branch of the feedback project; every other profile (including YAML-file profiles) posts to the production feedback project. Connection constants live in src/shared/feedback/feedback-client.layer.ts.

How feedback delete <token> works

• Validation: the token must be a UUID (checked client-side to avoid PostgREST's cryptic uuid-cast error) and is lowercased before sending.
• No read, ever: the CLI never fetches the feedback text. Deleting is harmless to the user (the row exists for Supabase's benefit), so nothing is shown first; the only request is the DELETE below. With no client reading rows, the backend's anon read path has nothing to serve and is removed in a follow-up (CLI-2406). The delete policy is unchanged.
• Confirmation: interactive text mode prompts (Permanently delete this feedback? [y/N]) as the guard against a mistyped or pasted token; --yes/SUPABASE_YES skips it. The prompt runs before the row's existence is known, so a wrong token gets the prompt and then the not-found error. Machine modes (json/stream-json, and -o json) fail loudly without --yes rather than deleting silently — same contract as logout. Both stdin and stdout must be TTYs for the prompt, so printf 'y' | supabase feedback delete <token> cannot confirm a delete without --yes.
• Deletion: a hard DELETE with Prefer: count=exact; the CLI verifies Content-Range reports exactly one row. Zero rows → a friendly not-found error covering all three indistinguishable causes (wrong token, already deleted, project-ref/user-id context mismatch). Authorization is the x-feedback-token request header matched by RLS — the delete_token=eq. URL filter only satisfies PostgREST's filterless-delete rejection. --debug request lines redact the filter.
• Context gate: rows submitted from a linked project also require the matching x-feedback-project-ref header, and rows submitted while logged in require x-feedback-user-id. The delete command resolves the ref as --project-ref → SUPABASE_PROJECT_ID → linked-ref file (flag and env validated, file soft) and always sends whatever resolves (extra context against a context-free row is ignored server-side). The user-id header is not consent-gated: it is functional auth context, and gating it would strand rows submitted before an opt-out.
• Machine modes return an acknowledgement only: --output-format json gives { "message": "Feedback deleted." }, -o json gives { "deleted": true }.

Privacy note for reviewers

The feedback message, the delete token, and the --project-ref value go only to the feedback backend — never to PostHog. Message and token are positional arguments, which extractChangedFlagNames structurally excludes from the flags telemetry property; --project-ref is recorded by name only with its value redacted. Regression tests assert none of them appear in captured analytics events. user_id is sent to the feedback backend under the conditions above and is documented in add/SIDE_EFFECTS.md.

Reviewer-relevant context

• The shared service was reshaped from FeedbackSubmitter (insert-only) into FeedbackClient (submit/delete) in src/shared/feedback/feedback-client.{service,layer}.ts, and the profile→environment mapping and cli-config layer wiring were hoisted to the feedback family root (feedback.layers.ts, feedback-project-ref.ts) now that two commands share them.
• FeedbackBackendError carries a reason (response vs transport) so a PostgREST rejection classifies as apiStatus in error telemetry while network failures stay externalNetwork. postgrest-js reports fetch rejections, timeouts, and aborts as an error envelope with status: 0, which is the discriminator.
• The feedback client speaks fetch (supabase-js), not Effect's HttpClient, so --debug logging and --dns-resolver https compose at the fetch boundary (feedbackFetch). Along the way the shared DoH wrapper gained two fixes that apply to every command: WHATWG Headers instances survive the rewrite, and the request's abort signal now cancels the DoH lookup itself.
• src/shared/feedback/database.types.ts is generated (pnpm gen:feedback-types, from the production project) and excluded from formatting/knip; it is marked linguist-generated.
• The real-backend golden path (add → delete round trip against the staging branch, cleaning up its own row) is add.live.test.ts under the gated live project. The default e2e file only exercises subcommand routing with zero network.
• The commands are registered in docs-spec.tables.ts (other-commands tag) and each has a SIDE_EFFECTS.md.
• Heads-up on CommandSettings.projectId: it is a bare SUPABASE_PROJECT_ID env passthrough — it does not read config.toml or the linked-project file, so it is None in a linked project unless that env var is set. An earlier revision of this branch used it directly as "the linked project ref", which meant project_ref was always null in practice. The agent-guide row that described it as resolving project-id from config.toml was corrected here, since that phrasing is what made the field look project-aware.
• services.integration.test.ts now uses an isolated temp workdir instead of process.cwd(), fixing machine-dependent behavior when the developer has local supabase start state.

🤖 Generated with Claude Code

[chatgpt-codex-connector]

💡 Codex Review

Here are some automated review suggestions for this pull request.

Reviewed commit: 656f13a667

ℹ️ About Codex in GitHub

Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you

• Open a pull request for review
• Mark a draft as ready
• Comment "@codex review".

If Codex has suggestions, it will comment; otherwise it will react with 👍.

Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".

[github-actions]

Supabase CLI preview

npx --yes https://pkg.pr.new/supabase/cli/supabase@d6a27ec0881fa27a12993e6bf312b5cbf44a69e8

Preview package for commit d6a27ec.

[chatgpt-codex-connector]

💡 Codex Review

Here are some automated review suggestions for this pull request.

Reviewed commit: 830e565f2a

ℹ️ About Codex in GitHub

Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you

• Open a pull request for review
• Mark a draft as ready
• Comment "@codex review".

If Codex has suggestions, it will comment; otherwise it will react with 👍.

Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".

[chatgpt-codex-connector]

💡 Codex Review

Here are some automated review suggestions for this pull request.

Reviewed commit: ae5d202bd6

ℹ️ About Codex in GitHub

Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you

• Open a pull request for review
• Mark a draft as ready
• Comment "@codex review".

If Codex has suggestions, it will comment; otherwise it will react with 👍.

Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".

[chatgpt-codex-connector]

💡 Codex Review

Here are some automated review suggestions for this pull request.

Reviewed commit: 4ca265f84d

ℹ️ About Codex in GitHub

Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you

• Open a pull request for review
• Mark a draft as ready
• Comment "@codex review".

If Codex has suggestions, it will comment; otherwise it will react with 👍.

Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".

[kanadgupta]

Addressed the open review threads on the branch (each in its own commit):

• Security: control characters stripped from the text-mode delete preview; -o json never prompts (stdout stays payload-only).
• Correctness: a piped-stdin read failure discards the partial buffer instead of submitting it; malformed --project-ref/SUPABASE_PROJECT_ID fail with the shared invalid-ref error like every other command; the delete hint includes --project-ref when the row carried one; DoH resolution is cancelled with the request.
• Telemetry: FeedbackBackendError distinguishes backend responses (apiStatus) from transport failures (externalNetwork).
• Docs: SIDE_EFFECTS.md reflects the dedicated production project and the task log events in machine output; the PR description no longer claims user_id is never sent.

Left open with replies: the delete-token URL filter (needs a backend RPC), the Request-input DoH rewrite, and the UUID-pattern hoist (follow-ups). edit: marked these as resolved

[avallete]

Looks good — add/delete contracts hold (TTY/-o json gates, piped discard, consent-gated user_id, debug redact, DoH Headers + abort).

Non-blocking follow-ups inline: declare --project-ref on feedback add (same as delete), drop the remaining Go PersistentPostRun framing, and reuse BRANCH_UUID_PATTERN in delete.

[mattrossman]

Tested the command working on my end 👍

One design question I have after playing w/ this is whether we should prohibit reads of feedback on backend. IIUC that is the main reason for the extra project ref / user ID checks. I'd think that since the motivating risk is a user accidentally submitting sensitive data, it should be easy to delete and hard to read. Currently it's a little backwards of that philosophy in some ways. If you forget which project / account feedback was associated you might lose the ability to delete it even if you have the UUID, or if you submitted it without an associated project/user then others can read that feedback if they obtain the UUID. I was surprised to see it print out the submitted feedback (or a confirmation at all) before deletion since there's no harm to the user in deleting feedback, it's mainly for our benefit.

Risk is low anyway so not thinking of that as a blocker, just a thought.

[kanadgupta]

One design question I have after playing w/ this is whether we should prohibit reads of feedback on backend. IIUC that is the main reason for the extra project ref / user ID checks. I'd think that since the motivating risk is a user accidentally submitting sensitive data, it should be easy to delete and hard to read. Currently it's a little backwards of that philosophy in some ways. If you forget which project / account feedback was associated you might lose the ability to delete it even if you have the UUID, or if you submitted it without an associated project/user then others can read that feedback if they obtain the UUID. I was surprised to see it print out the submitted feedback (or a confirmation at all) before deletion since there's no harm to the user in deleting feedback, it's mainly for our benefit.

Thanks @mattrossman! Appreciate you providing some fresh perspective on this — I understand why this could be confusing. I'll include some context on my thought process around this design (e.g., a confirmation prompt with the content preview) below:

• feedback delete will be useful in the event that an agent submits feedback without the human's consent (or furthermore, in the event that a human wants feedback to be submitted, but the agent includes something in the feedback that it shouldn't have)
• depending on the human's setup, it might not be possible for them to see the feedback that was submitted by the agent, so they may be unsure whether the feedback should be deleted or not
• because of this, it would be helpful to have the ability to preview the feedback and decide at that point whether or not it should be deleted
• if a human/agent wants to delete feedback en masse without looking at the content, they can include --yes to bypass all prompts (this is a global flag that is supported in every command with prompts)
• users are somewhat likely to switch between projects (e.g., supabase link), but much less likely to switch between user accounts (e.g., supabase login), so including the actual --project-ref in the submission confirmation message should (hopefully?) set the user up for success in the deletion workflow
• if we (i.e., Supabase) want to delete feedback that's gated behind a project ref / user ID, we can go into the backend table and delete it ourselves

Let me know if this thought process (all of which is completely based on my hunches 🙃) doesn't match your understanding, and/or any changes you'd like to see.

This is Claude's suggestion for next steps if we do want to remove the preview/confirmation:

The cleanest fix based on this feedback is on the backend: a SECURITY DEFINER delete RPC keyed by token, with no select grant on the table. That removes the read path entirely and lets the CLI drop the preview (and arguably the confirmation) since there is nothing to show. I'd rather take that as a deliberate follow-up under CLI-1946 than change the CLI shape in this PR while the backend still exposes the read.

[mattrossman]

@kanadgupta That makes sense. I'm fine to keep it as-is to unblock this, and ideally make that proposed security change as a follow-up.

Assuming users have a record of the output of this command (which they'd need in order to delete anyways), I think it's reasonable to assume they have a record of the input feedback too. For instance I know Claude can chug away running commands without keeping you in the loop of everything it ran, but it still keeps the command history recorded in the session so you can ask it what was submitted. If I know my agent submitted feedback but it isn't able to tell me what it submitted, I'd prob err on the side of deletion anyway. Just my 2 cents, but maybe you had a different situation in mind where user can see the output but not input.

Anyways, not a blocker to this PR I don't think. Approving from a functionality POV, I'll leave it to CLI team for the implementation details approval.

[kanadgupta]

Assuming users have a record of the output of this command (which they'd need in order to delete anyways), I think it's reasonable to assume they have a record of the input feedback too. For instance I know Claude can chug away running commands without keeping you in the loop of everything it ran, but it still keeps the command history recorded in the session so you can ask it what was submitted. If I know my agent submitted feedback but it isn't able to tell me what it submitted, I'd prob err on the side of deletion anyway.

@mattrossman agreed with this and you've convinced me! I decided to make the following change in 0adce4c:

• feedback delete no longer previews. The CLI never reads feedback text now; the only request it makes is the token-scoped DELETE.
• The confirmation prompt stays as a guard against a mistyped or pasted token. It runs before the row's existence is known, and a wrong token gets the not-found error after it. --yes still skips it, and machine modes still require --yes.
• Machine payloads are just the acknowledgement: --output-format json gives { "message": "Feedback deleted." }, -o json gives { "deleted": true }.
• The delete policy is unchanged (token plus matching project/user context when the row was submitted with them).

With no client reading rows, the backend's anon read path has nothing to serve, so removing the select grant and read policy is tracked in CLI-2406 as a follow-up. That closes the "others can read it if they get the UUID" half without touching the CLI again.