Cloud thread reply attaches to wrong local workspace

What version of the Codex App are you using (From “About Codex” dialog)?

26.305.950 (863)

What subscription do you have?

Pro

What platform is your computer?

Darwin 25.3.0 arm64 arm

What issue are you seeing?

Replying to a Cloud thread from one environment can create or continue a local thread in a different local workspace. The conversation history reflects the original project, but execution runs in the currently active local repo.

Expected:

Actual:
The reply executed in /Users/adc/dev/pbf even though the prior conversation context belonged to a different project/environment.

Impact:
Codex can inspect or modify the wrong repository. In this case, it responded about an Angular UI change while running in a Go repo.

Evidence:

The active execution context for the reply was /Users/adc/dev/pbf.
The app had multiple known workspaces, including /Users/adc/dev/pbf and /Users/adc/cap/cap-tally.
The current active local workspace was pbf.
Older threads had stored workspace hints for cap-tally.
The newer thread created from the Cloud reply appeared to lack the expected workspace binding and ran in the active local workspace instead.

What steps can reproduce the bug?

Steps to reproduce:

1. Open a Cloud thread associated with environment A.
2. In the desktop app, make local workspace B the active workspace.
3. Reply to the Cloud thread.
4. Observe which workspace the reply executes in.

The reply executes in the currently active local workspace, even though the prior conversation context belongs to a different project/environment.

What is the expected behavior?

The reply should remain bound to environment A, or the app should prompt for the target workspace before execution.

Additional information

Evidence:

The reply ran in a different local workspace than the one implied by the original Cloud thread.
The app had multiple known workspaces.
Older threads appeared to retain workspace associations.
The newer thread created from the Cloud reply appeared to lose or ignore the expected workspace binding and instead ran in the active local workspace.