Describe the bug
A successful live reinitialization silently replaces manually edited text in the Chat converter working copy with the original composer text. An administrator applying configuration in another tab can therefore discard another user's unsent work.
The original composer text and saved conversation history survive. The lost text is the distinct text the user entered only in the working copy. This was reproduced both with a Base64 pipeline and independently with no converter configured, so it is not limited to an incompatible converter or a stale generated preview.
Severity: P1 / High, because user-entered text is lost without a warning or recovery copy. Observed after the live-reinitialization feature in #2833.
Steps/Code to Reproduce
Use an isolated, single-process local development instance with live reinitialization enabled in the saved configuration:
enable_live_reinitialization: true
Use a configured target that will retain the same registry identity after reinitialization. No external provider request is needed to reproduce the text loss.
- Open Chat and select that target.
- Enter
Original summary: compare two invented support tickets. in the composer without sending it.
- Open Converters. Replace the Working input text with
UNSAVED HUMAN EDIT: Keep the detailed comparison and the next action; this text exists only in the converter working copy. Do not add a converter or send the message.
- Keep the Chat tab open. In another administrator tab, open Configuration and click Reinitialize PyRIT.
- Confirm Reinitialize PyRIT in the all-users confirmation dialog, using valid saved sources.
- Wait for reinitialization to succeed and for Chat to become ready again.
- Inspect the Working input field in the original tab.
Expected Results
The user-authored working-copy text remains available after a successful runtime generation change. Generated conversion results may be invalidated or require reconversion, but that should not discard manual edits.
A regression test should cover both a working copy with an existing converter pipeline and one with no converter configured.
Actual Results
| Field |
Before reinitialization |
After reinitialization |
| Composer |
Original summary: compare two invented support tickets. |
Unchanged |
| Working input |
UNSAVED HUMAN EDIT: Keep the detailed comparison and the next action; this text exists only in the converter working copy. |
Original summary: compare two invented support tickets. |
| Configured target |
Same registered target |
Same registered target |
| Runtime result |
Ready |
New generation, ready, successful apply |
There was no warning before the replacement. The original composer cannot recover the deleted edit because it never contained that text.
The generation-change effect in useChatConverters.ts, lines 176-190 clears workingInputs together with generated stage results and applied values. User-authored working text needs to be preserved separately from those invalidated results.
Screenshots
Captured in the September 25 catch-up audit artifacts, not uploaded to this issue:
daily-2026-09-25-catchup/manual/runtime-manual-edit-before.png
daily-2026-09-25-catchup/manual/runtime-manual-edit-lost-after.png
- Independent before/after observations:
daily-2026-09-25-catchup/manual/runtime-generation-followup.json
The steps and observed values above are self-contained; the artifact files are not required to reproduce the problem.
Versions
- OS: Windows, x86-64.
- Browser: Chromium through Playwright; focused reproduction at 1440 x 900.
- Python: CPython 3.14.4, uv-managed environment.
- PyRIT:
1.2.0.dev0, editable source checkout at c32546a1e3d069ea9794df31ded86e17487dcf2a.
- Local-only backend with in-memory persistence and an unchanged configured target identity. No live external provider was used.
- Full
pyrit.show_versions() output was not captured.
Describe the bug
A successful live reinitialization silently replaces manually edited text in the Chat converter working copy with the original composer text. An administrator applying configuration in another tab can therefore discard another user's unsent work.
The original composer text and saved conversation history survive. The lost text is the distinct text the user entered only in the working copy. This was reproduced both with a Base64 pipeline and independently with no converter configured, so it is not limited to an incompatible converter or a stale generated preview.
Severity: P1 / High, because user-entered text is lost without a warning or recovery copy. Observed after the live-reinitialization feature in #2833.
Steps/Code to Reproduce
Use an isolated, single-process local development instance with live reinitialization enabled in the saved configuration:
Use a configured target that will retain the same registry identity after reinitialization. No external provider request is needed to reproduce the text loss.
Original summary: compare two invented support tickets.in the composer without sending it.UNSAVED HUMAN EDIT: Keep the detailed comparison and the next action; this text exists only in the converter working copy.Do not add a converter or send the message.Expected Results
The user-authored working-copy text remains available after a successful runtime generation change. Generated conversion results may be invalidated or require reconversion, but that should not discard manual edits.
A regression test should cover both a working copy with an existing converter pipeline and one with no converter configured.
Actual Results
Original summary: compare two invented support tickets.UNSAVED HUMAN EDIT: Keep the detailed comparison and the next action; this text exists only in the converter working copy.Original summary: compare two invented support tickets.There was no warning before the replacement. The original composer cannot recover the deleted edit because it never contained that text.
The generation-change effect in useChatConverters.ts, lines 176-190 clears
workingInputstogether with generated stage results and applied values. User-authored working text needs to be preserved separately from those invalidated results.Screenshots
Captured in the September 25 catch-up audit artifacts, not uploaded to this issue:
daily-2026-09-25-catchup/manual/runtime-manual-edit-before.pngdaily-2026-09-25-catchup/manual/runtime-manual-edit-lost-after.pngdaily-2026-09-25-catchup/manual/runtime-generation-followup.jsonThe steps and observed values above are self-contained; the artifact files are not required to reproduce the problem.
Versions
1.2.0.dev0, editable source checkout atc32546a1e3d069ea9794df31ded86e17487dcf2a.pyrit.show_versions()output was not captured.