Preserve temporary message in Studio Code UI

[nightnei]

Related issues

• Fixes STU-1829

How AI was used in this PR

AI wrote the code, I reviewed and made a few manual adjustments.

Proposed Changes

I had a case where I was writing a prompt, then needed to switch to the site Settings tab and come back — and as a result, I lost my prompt draft.

AFAIK, it’s a common UX expectation to preserve drafts when the app state changes or when the user temporarily leaves the form.

Testing Instructions

1. npm start
2. Open Studio Code tab for site A and write "1111" (don't submit it)
3. Open Studio Code tab for site B and write "2222" (don't submit it)
4. Come back to site A and assert that you still see 1111
5. Come back to site B and assert that you still see 2222
6. Try to test it with submitting/clearing the form, switching tabs / coming back, and asserting that everything works well

[wpmobilebot]

📊 Performance Test Results

Comparing 5d179b6 vs trunk

app-size

Metric	trunk	5d179b6	Diff	Change
App Size (Mac)	2328.95 MB	2328.96 MB	+0.00 MB	⚪ 0.0%

site-editor

Metric	trunk	5d179b6	Diff	Change
load	1711 ms	1720 ms	+9 ms	⚪ 0.0%

site-startup

Metric	trunk	5d179b6	Diff	Change
siteCreation	8504 ms	8534 ms	+30 ms	⚪ 0.0%
siteStartup	3920 ms	3877 ms	43 ms	⚪ 0.0%

---

Results are median values from multiple test runs.

Legend: 🟢 Improvement (faster) | 🔴 Regression (slower) | ⚪ No change (<50ms diff)

[sejas]

Thanks for implementing this improvement. The happy path works great. I just noticed that, in an existing conversation, when clicking “New conversation,” it leaves the draft message in localStorage. It would be great to remove that item as well.

Also, I wonder if it makes sense to keep the text input populated with the existing value when clearing the conversation, although trunk behaves the same way and clears the text input too.

Happy Path

happy-path-keep-draft-input.mp4

New conversation left over

leaving-draft-saved-in-localstorage.mp4

[nightnei]

@sejas

I just noticed that, in an existing conversation, when clicking “New conversation,” it leaves the draft message in localStorage. It would be great to remove that item as well.

Great catch 👍 Addressed

Also, I wonder if it makes sense to keep the text input populated with the existing value when clearing the conversation, although trunk behaves the same way and clears the text input too.

I don’t see specific advantages to either approach. So for now, I would propose to leave things as they are.

[katinthehatsite]

Also, I wonder if it makes sense to keep the text input populated with the existing value when clearing the conversation, although trunk behaves the same way and clears the text input too.

I was expecting it to be reset when I tested this but I find a bit of a strange flow, especially when I am using the templates provided:

• Start on site A and use one of the prompts
• Don't sent the message
• Click on New conversation
• Observe the prompt is not cleared
• Switch to site B
• Switch back to site A and observe the prompt is now cleared from site A

Screen.Recording.2026-06-16.at.10.17.28.AM.mov

[sejas]

The issue of leaving the draft in local storage after starting a new conversation is fixed. Thanks!
The issue that Kat mentions seems to be related to this change. I see an inconsistent behaviour when:

1. Typing text in the text input
2. Click on start a new conversation
3. Observe the text input is still in the text input
4. Change sites or tabs
5. Come back to previous conversation
6. Observe your draft text input is gone

[nightnei]

The issue of leaving the draft in local storage after starting a new conversation is fixed. Thanks! The issue that Kat mentions seems to be related to this change. I see an inconsistent behaviour when:

1. Typing text in the text input
2. Click on start a new conversation
3. Observe the text input is still in the text input
4. Change sites or tabs
5. Come back to previous conversation
6. Observe your draft text input is gone

Yeah, fixed
It turns out that it's an existign bug/behaviour in the trunk

[sejas]

I confirm now that it’s consistent, and clicking “New conversation” always removes the text input immediately. I think it's open for discussion if that's the expected behaviour but at least is consistent. I think we can merge this PR and decide if we want to keep the value in the text input or not.

Also, I wonder if it makes sense to keep the text input populated with the existing value when clearing the conversation, although trunk behaves the same way and clears the text input too.

I don’t see specific advantages to either approach. So for now, I would propose to leave things as they are.

new-conversatio-removes-input.mp4

I confirmed that Claude resets the text input when clicking on a new chat within existing conversations, although it keeps the text input if your chat didn't start yet.

claude-new-conversation-clears-input-too.mp4