GeezerVison

Summary

This PR intentionally changes no behavior. It pins an existing trade-off in place, documents it, and removes a footgun. No redaction logic is touched.

#6591 turned on redactOpaqueCredentialInputs for the workflow export path. That closed a real leak: a bearer token pasted into an API block's Headers cell, and secrets in custom tool params, were reaching the v1/v2 export APIs and the in-app Export as JSON in plaintext.

Its unpriced cost shipped with it. An export/import round trip now returns API blocks with empty Headers and Query Params, and drops {{ENV_VAR}} references inside table cells even though the same reference in a password field survives. Nothing in the test suite described either side of that trade, so it could be flipped in either direction without anyone noticing — and an earlier audit did recommend reverting the flag.

• adds round-trip fixtures (an api block with two table sub-blocks, an agent block with a custom tool) plus assertions pinning the current loss
• records the trade on redactOpaqueCredentialInputs — which surfaces it governs, what is lost, why withholding beat per-cell heuristics, and the shape a future relaxation must take
• deletes a duplicate sanitizeForExport in credential-extractor.ts
• corrects two route TSDocs that misdescribed what the code does, and moves the canonical sanitization doc onto the symbol those docs link to

The tests guard in both directions

Not just "redaction still works" — reverting the flag now fails loudly. Setting redactOpaqueCredentialInputs: false in json-sanitizer.ts produces exactly 4 failures:

× redacts nested tool credentials from the public export payload
× withholds table values, including whole {{ENV_VAR}} cells, on the way out
× withholds every parameter of a tool with no authoritative codec metadata
× re-imports the withheld sub-blocks as empty rather than dropping or corrupting them

The first one is the point: it is executable proof that reverting the flag re-opens a secret leak. The other three pin the accepted cost, so anyone who decides the loss is unacceptable has to edit those expectations deliberately rather than delete the flag and ship.

The deleted duplicate was a real footgun

credential-extractor.ts exported its own sanitizeForExport that called sanitizeWorkflowForSharing with preserveEnvVars: true and not redactOpaqueCredentialInputs. It had zero production importers — every real caller uses the same-named but different function in @/lib/workflows/sanitization/json-sanitizer, which does pass the flag and returns a full envelope.

Its only consumer was a test suite, which therefore described a configuration nothing runs. Two identically-named exports where one silently omits a redaction flag is exactly the shape of a future leak. The suite now passes the real option set explicitly, and import-export-roundtrip exercises the genuine sanitizeForExport, so the copy cannot drift unnoticed.

Open question for the owner

This PR does not resolve the underlying tension, because it is a product decision, not an engineering one:

Is workflow export a faithful backup format, or a share-safe projection?

Those two goals conflict here and the answer decides any future change. Today the export path tries to be both and lands as a share-safe projection that people reasonably expect to be a backup. If it is a backup, the fix is a per-sub-block opt-in that fails closed for tables added later — never a wider default. If it is a share-safe projection, the current loss is correct and the gap is discoverability: nothing in the product or the logs tells a user their tables came back empty; they find out by re-importing.

Worth noting the first relaxation candidates are already visible in the new fixture — api.params (query params) and response-shaping header tables are not credential sinks.

Recommended next action: discoverability, not relaxation

Independent of how that question is answered, the concrete follow-up I'd recommend is telling the user what was withheld — surface a warning on export (and on import) that table sub-blocks and unauthoritative tool params came back empty and must be re-entered.

That is the right next step because it is the only option with no security trade: it does not widen what is exported by a single byte, so it cannot re-open the leak #6591 closed, and it works whichever answer the product question gets. It converts a silent loss into an informed one. Today a user discovers the loss by re-importing a workflow and finding empty Headers — which is also why this reached a release unnoticed.

Relaxing the redaction (a per-sub-block opt-in that fails closed) is the larger, riskier change and should wait on the product decision. Discoverability should not.

Type of Change

• Chore / test + docs (no behavior change)

Testing

35/35 passing across import-export-roundtrip, credential-extractor, and export-workflow. Bidirectional guard verified by flipping the flag and confirming 4 failures, then restoring. bun run type-check clean, biome clean.

Checklist

• Code follows project style guidelines
• Self-reviewed my changes
• Tests added/updated and passing
• No new warnings introduced
• I confirm that I have read and agree to the terms outlined in the Contributor License Agreement (CLA)