Jack Chen
6b6330208c
* fix: redact secrets in traces, bash env, and dashboard payloads Adds src/utils/redaction.ts and applies best-effort redaction at three sinks where sensitive data could leak: - tool_call trace events (input, output) - the bash tool's output buffer - the post-run dashboard's embedded JSON payload The bash tool no longer inherits the parent process.env. Child processes receive a fixed allowlist (HOME, LANG, LC_ALL, LOGNAME, PATH, SHELL, TEMP, TERM, TMP, TMPDIR, USER), so provider API keys and similar secrets are no longer visible to spawned shells. The post-run dashboard no longer loads Tailwind CDN, Google Fonts, or Material Symbols at view time. The page is self-contained and renders without network access. llmMessagesToAiSdkModelMessages no longer concatenates the opaque redactedData payload into the reasoning text emitted to the AI SDK; it emits only the [redacted_thinking] marker. The MCP GitHub example uses --no-install instead of -y and passes an explicit env allowlist instead of spreading process.env. * fix(redaction): consume full value for quoted and unquoted assignments The single ASSIGNMENT_PATTERN stopped at the first whitespace inside a value, so values with spaces were only partially redacted and the remainder leaked into trace events, dashboard payloads, and the bash output buffer. Three reviewer-reported cases on PR #263: password=secret value -> password=[redacted] value password="secret value" -> password="[redacted]" value" apiKey: "abc def" -> apiKey: "[redacted]" def" Splits the single pattern into two passes. The quoted pass consumes to the back-referenced closing quote so password="my pass" is fully matched. The unquoted pass consumes to the next structural delimiter (comma, semicolon, brace, bracket, newline) so password=my pass is fully matched. Adds tests/redaction.test.ts covering the three reviewer cases, the existing Authorization orphan-bracket regression, common token literal patterns, and idempotence.
examples/integrations/
OMA wired to external systems: MCP servers, observability backends, other frameworks, app shells. Runnable starting points, not product docs.
Two categories live here.
Reference integrations demonstrate wiring against widely used protocols or frameworks. The OMA team maintains these once merged, regardless of who contributed them. Current:
mcp-github.ts: MCP servers viaconnectMCPTools().trace-observability.ts: theonTraceAPI.with-vercel-ai-sdk/: Next.js + AI SDK +runTeam().express-customer-support/: Express REST API +runTasks(). Contributed by @CodingBangboo via #191.
Vendor integrations show OMA paired with a specific third-party
commercial product. They live under with-<product>/ and stay credited to
the contributor. Current:
with-engram/: Engram memory backend. Contributed by @Agentscreator via #160.
Submitting a reference integration
Open a PR following the conventions in examples/README.md.
For widely used protocols or frameworks, no prior discussion needed. For
niche ones, open a discussion first so we can confirm the wiring is worth
maintaining long-term.
Submitting a vendor integration
One condition: the integration is reciprocal. Your product's repo or docs should reference OMA as a supported integration. No payment involved, this is a signal filter for who has actually shipped against OMA.
Flow:
- Open a discussion with the link to OMA in your product's docs and a sketch of the example.
- Wait for a maintainer reply confirming the example is in scope.
- PR it. Follow the conventions in
examples/README.md.
If your product doesn't reference OMA yet, open a discussion to get listed in the Ecosystem section.
The Featured Partner program is separate and paid, for prominent README placement. Eligibility is an active OMA integration; reciprocal listing isn't required.
Out of scope here
- Marketing copy for a third-party product.
- Examples gated behind paid-only APIs with no free or trial tier.
- Thin
connectMCPTools()wrappers whose only difference frommcp-github.tsis the server name and prefix. Those belong in your own docs.