Promptise Foundry 1.10.1

Security

• With scan_tool_results=True, trace_tools and an observer showed the raw tool result -- the model got the redacted result, but MCP tools and wrapped native tools reported the result from inside the tool, before the scan, so the console line and the trace's result_preview held the PII or secret the scan had removed. They now show the result the model gets: the redacted text, or the withheld notice. observe=True traces were not affected.

Fixed

• An MCP server approval handler that raised an error gave the client INTERNAL_ERROR -- the call was refused, but with no approval reason and no request id. ApprovalGateMiddleware now denies with APPROVAL_DENIED, "approval handler error: " in the message and approval_request_id in the details, like the agent's gate; the error itself goes to the server log. A handler that raises an MCPError (such as ApprovalDeniedError) still has it sent as is.
• A sandbox container that failed to start was left behind -- DockerBackend.create_container created the container, and when start() failed (for example an image without /bin/bash) it raised without removing it, so docker ps -a kept a Created container for every failed session. It is now removed before the error is raised.
• Breaking out of astream() or astream_with_tools() logged "Task exception was never retrieved: ValueError: <Token ...> was created in a different Context" -- a consumer that leaves async for with break leaves the stream to the event loop, which closes it in another task, where resetting the run's context variables failed. The stream now cleans up there quietly. Wrapping the stream in contextlib.aclosing() still closes it at once.
• A scanner set to BLOCK PII or credentials without redact_input=True now says it doesn't block input -- on input those findings are warnings unless redact_input=True, so CredentialDetector(action=Action.BLOCK) alone never refused a message. PromptiseSecurityScanner now logs a warning when it is created with such a setting. Behaviour is unchanged.
• The promptise run event bus could count one failing subscriber twice -- a subscriber that raised in two publishing threads at the same time was dropped once but added to EventBus.dropped_subscribers by both, and the count was updated outside the bus lock. Only the thread that removes it counts it now.

Docs

• The event payload table lists streaming for invocation.timeout.

Full changelog: https://docs.promptise.com/resources/changelog/#v1101-2026-10-24