The software's workbench layout function has a vulnerability.

[usercao]

What happened

The software's workbench layout function has a vulnerability.

Steps to reproduce

After deleting the current workspace and opening a new workspace, the layout of the previous workspace is reset.

Expected behavior

Environment

• OS and version: macOS 26.5.2
• Voleeo version / commit: 0.16.0
• Using the MCP bridge? (yes/no, which client): no

[axbarchuk]

Hi @usercao, could I ask to attach some screenshots to show the behaviour before and after?

[usercao]

1. My current saved work layout

2. Click Delete

3. Close the software and reopen a new workspace (Please note my software width)

a. Why I am confused about this is because in other software, layout should be a setting of the entire software and not associated with the workspace. I am not sure if this is a feature of this software.

b. I'm not sure if this is related to the problem. My current work environment is a MacBook with an external monitor. The software is usually opened on the external monitor. I have to manually drag it to the MacBook every time. Is it possible to add a memory function? Because Postman can be pinned to a specific monitor.

c. Thank you for developing Voleeo. Over the past few weeks, I've tested all the HTTP clients on the market, but I've been using Postman for various reasons. Yesterday I saw Voleeo in an article, tried it today, and uninstalled Postman. In my opinion, it's currently the best HTTP client. I hope it continues to improve.

[axbarchuk]

Hi @usercao, why did you close this bug, do not reproduce anymore? I just didn't have time yet to take a look.

[usercao]

I apologize, I previously thought you couldn't reproduce this problem (perhaps due to a unique computer environment?), so I closed this question.

I found another way to reproduce the problem:

1. Change the current layout and then close the software.

2. Reopen the software and click the Git Sync button.

3. Then close the software.

Upon reopening, the layout from step 1 will have been reset.

[axbarchuk]

@usercao thanks for opened issue. When I will have a bit spare time I will take a look at this bug.

[lucasAguiar11]

Hey, I ran into this too and dug around a bit. It's not only the layout — opening the Source Control window wipes the whole settings entry for that workspace on disk.

Watched workspace-settings.yaml while doing it. Before:

- id: <workspace>
  openedAt: 2026-08-05T18:21:00.400Z
  windowSize:
    width: 1229.0
    height: 776.0
  itemsCount: 0

Right after clicking Source Control:

- id: <workspace>
  itemsCount: 0

Everything else is gone, and on a workspace with resized panels panelSizes/panelLayout go the same way — hence the reset on next launch.

What seems to happen: the git window skips loadAllSettings() on boot (App.tsx:71-75), but it still loads the request store, and that store saves the item count whenever requests change (store/requests/index.ts:79-83). patchSettings merges onto an empty cache there, so it sends just { itemsCount: N } — and workspace_save_settings replaces the whole entry with it (settings.rs:144).

Funny enough the comment right above the bootstrap call already warns about this for other secondary windows, the git one just isn't covered.

Fixing it in the Rust side (merge per field instead of replacing) would cover any window, present or future. Doing it only in the frontend fixes this one path.