Environment
- Product: Codex Remote Feishu
- Version: v1.8.4
- Platform: macOS
- Surface: Feishu group chat, bot mentioned with
/workspace new dir
What happened
In a Feishu group chat, I tried to attach an existing local directory as a workspace:
- Mention the bot in a group chat:
@bot /workspace new dir
- Choose an existing local directory, for example
/Users/<local-user>/codex-remote-hh
- Leave the optional "create new directory under this directory" field empty
- Click "接入并继续"
Nothing visibly happens in Feishu. The card remains on the same picker state, and no workspace conversation is entered.
The same also happens if I enter a new directory name and click "创建并继续".
Expected behavior
After choosing a directory and clicking the confirm button, the group chat surface should attach to the selected workspace and enter a new Codex conversation.
Actual behavior
The button callback reaches the daemon, but it only re-renders the target picker card repeatedly. The workspace is not attached.
Relevant local log pattern:
surface action: ... kind=surface.target_picker.confirm ...
ui event: ... kind=target.picker
surface action: ... kind=surface.target_picker.confirm ...
ui event: ... kind=target.picker
No permission or Feishu callback failure was observed. The gateway stayed connected, and manually editing surface-resume-state.json to bind the same group surface to the same local directory made the group chat work immediately.
Possible cause
This looks related to applyTargetPickerDraftAnswers in internal/core/orchestrator/service_target_picker_add_workspace.go.
When the callback contains FeishuTargetPickerLocalDirectoryNameFieldName, the code resets:
record.LocalDirectoryName = strings.TrimSpace(value)
record.LocalDirectoryChecked = false
record.LocalDirectoryFinalPath = ""
On confirm callbacks, Feishu appears to send the input field value again, even if it is unchanged or empty. That clears LocalDirectoryChecked before the confirm path can complete, so the UI returns to target.picker instead of attaching the workspace.
Workaround used
I manually inserted a resume-state entry for the group surface with:
{
"resumeWorkspaceKey": "/Users/<local-user>/codex-remote-hh",
"resumeRouteMode": "new_thread_ready"
}After restarting the service, the daemon started a headless instance for that workspace and the group chat worked.
Environment
/workspace new dirWhat happened
In a Feishu group chat, I tried to attach an existing local directory as a workspace:
@bot /workspace new dir/Users/<local-user>/codex-remote-hhNothing visibly happens in Feishu. The card remains on the same picker state, and no workspace conversation is entered.
The same also happens if I enter a new directory name and click "创建并继续".
Expected behavior
After choosing a directory and clicking the confirm button, the group chat surface should attach to the selected workspace and enter a new Codex conversation.
Actual behavior
The button callback reaches the daemon, but it only re-renders the target picker card repeatedly. The workspace is not attached.
Relevant local log pattern:
No permission or Feishu callback failure was observed. The gateway stayed connected, and manually editing
surface-resume-state.jsonto bind the same group surface to the same local directory made the group chat work immediately.Possible cause
This looks related to
applyTargetPickerDraftAnswersininternal/core/orchestrator/service_target_picker_add_workspace.go.When the callback contains
FeishuTargetPickerLocalDirectoryNameFieldName, the code resets:On confirm callbacks, Feishu appears to send the input field value again, even if it is unchanged or empty. That clears
LocalDirectoryCheckedbefore the confirm path can complete, so the UI returns totarget.pickerinstead of attaching the workspace.Workaround used
I manually inserted a resume-state entry for the group surface with:
{ "resumeWorkspaceKey": "/Users/<local-user>/codex-remote-hh", "resumeRouteMode": "new_thread_ready" }After restarting the service, the daemon started a headless instance for that workspace and the group chat worked.