🔒 Aisle Security Analysis

We found 1 potential security issue(s) in this PR:

1. 🟡 Forced store=true for Azure OpenAI Responses requests may cause unintended data retention

Description

createOpenAIResponsesContextManagementWrapper mutates outgoing openai-responses payloads and forces payload.store = true when shouldForceResponsesStore(model) is true.

With this change, shouldForceResponsesStore now matches the azure-openai provider as well, meaning prompts/outputs for Azure OpenAI Responses requests can be flagged for provider-side storage even when upstream/default behavior was store:false.

Impact:

• For model.api === "openai-responses" and model.provider === "azure-openai" (and a direct Azure OpenAI base URL), the wrapper overwrites payload.store to true.
• This can unintentionally enable persistence/retention of end-user prompts and model outputs with the provider, potentially violating “no-store” expectations and organizational compliance requirements.
• There is no explicit opt-out knob in extraParams for the store override (other than setting compat.supportsStore=false, which is not a user-controlled privacy setting).

Vulnerable behavior (provider classification + forced mutation):

const OPENAI_RESPONSES_PROVIDERS = new Set(["openai", "azure-openai", "azure-openai-responses"]);
...
if (params.forceStore) {
  params.payloadObj.store = true;
}

Recommendation

Add an explicit configuration/guardrail so store=true is not silently enabled for Azure/OpenAI Responses requests.

Recommended options (pick one):

1. Require explicit opt-in (fail closed by default):

• Introduce an extra param such as responsesForceStore / allowResponsesStore.
• Only set payload.store = true when that flag is true.
• If Azure OpenAI would 400 without store=true, throw a clear error telling the operator how to opt in.

2. Allow explicit opt-out override:

• If the caller/config explicitly sets store: false, do not override it; instead surface a warning/error.

Example (opt-out respected + explicit error):

function applyOpenAIResponsesPayloadOverrides({ payloadObj, forceStore, ...rest }: Params) {
  if (forceStore) {
    if (payloadObj.store === false) {
      throw new Error("Azure/OpenAI Responses requires store=true; configure allowResponsesStore=true or switch APIs.");
    }
    payloadObj.store = true;
  }
}

Also document this behavior prominently (changelog/docs) so operators understand that Azure OpenAI Responses runs may store conversation data when enabled.

Analyzed PR: #42934 at commit d3285fe

_{Last updated on: 2026-03-11T08:05:30Z}

Greptile Summary

This PR fixes a regression introduced in 2026.3.8 where Azure OpenAI multi-turn cron jobs and embedded agent runs were failing with HTTP 400 "store is set to false". The root cause was that OPENAI_RESPONSES_PROVIDERS only contained "openai" and "azure-openai-responses", so the "azure-openai" provider configured with api: "openai-responses" never had pi-ai's upstream store: false overridden to true by shouldForceResponsesStore.

Key changes:

• openai-stream-wrappers.ts: Adds "azure-openai" to OPENAI_RESPONSES_PROVIDERS. The existing isDirectOpenAIBaseUrl guard already handles *.openai.azure.com hostnames, so the complete logic chain (api === "openai-responses" → provider in set → Azure base URL check) works correctly with no further changes.
• pi-embedded-runner-extraparams.test.ts: Adds a focused regression test that starts with { store: false } and asserts store === true after mutation, precisely mirroring the failing production scenario from issue bug: Azure OpenAI Responses API — store: false regression in 2026.3.8 breaks all multi-turn cron jobs #42800.
• CHANGELOG.md: Entry added with issue reference and contributor credit.

Note that shouldEnableOpenAIResponsesServerCompaction still only auto-enables server compaction for provider === "openai" (line 104), not for azure-openai. This appears intentional — Azure OpenAI Responses may not support the context_management compaction feature — but is worth awareness if that feature is extended to Azure in the future.

Confidence Score: 5/5

• This PR is safe to merge — it is a minimal, targeted bug fix with a direct regression test and no behavioural changes to unrelated code paths.
• The change is a one-token addition to a Set literal. The fix is logically correct: the missing provider entry was the exact cause of the regression, isDirectOpenAIBaseUrl already handles Azure hostnames, and all surrounding guard conditions (compat.supportsStore, API type check, base-URL check) remain fully intact. The new test exercises the precise failure scenario end-to-end and the PR author confirms the 67-test suite passes. Risk of unintended side-effects is essentially zero.
• No files require special attention.

_{Last reviewed commit: 19b3c46}

@codex review

Codex Review: Didn't find any major issues. Already looking forward to the next diff.

Merged via squash.

• Prepared head SHA: d3285fef41001bb25a8d1cb47a37ee9a132ffb9e
• Merge commit: dc4441322f9dc15f19de7bb89c3b2daf703d71e6

Thanks @ademczuk!