Remote project new-thread composer no longer exposes New worktree

Potential duplicates detected. Please review them and close your issue if it is a duplicate.

• #27013
• #27736

Powered by Codex Action

Additional source-level traceback

I dug further through the installed desktop app bundle and found the likely UI gating path that hides the run-location dropdown for remote-project new-thread creation.

In composer-DhWyK5QW.js, the composer computes the footer prop like this:

Xc = O === `home` && !F,
Zc = V || fo === `~` && !Xc || Ke && !Xc || F && !Xc,
Qc = {
  ...,
  hideRunLocationDropdown: Zc,
  ...,
  remoteConfig: {
    currentHostId: pi,
    getProjectPathForHostId: e => jn?.hostId === e ? jn.remotePath : y?.hostId === e ? y.projectPath : null
  }
}

Readable version:

const isHomeException = variant === "home" && !hideRunLocationDropdownOverride;

const shouldHideRunLocationDropdown =
  isSideComposer ||
  (workspaceRootForSubmit === "~" && !isHomeException) ||
  (isProjectlessConversation && !isHomeException) ||
  (hideRunLocationDropdownOverride && !isHomeException);

The important part is that the selected remote project path is supplied separately through remoteConfig, but the dropdown visibility is decided by the generic local/projectless workspace-root state (fo, Ke, F). So the composer can know about a selected remote project for branch/project-path purposes, while still hiding the run-location dropdown because the generic footer logic thinks it is projectless / ~ / explicitly hidden.

Relevant surrounding values from the minified bundle:

Gn = Y_({
  sharedPrefillCwd: Un,
  locationPrefillCwd: Hn,
  localConversationCwd: Re,
  selectedRemoteProjectPath: jn?.remotePath ?? null,
  defaultCwd: b,
  workspaceRoots: Wn,
  activeWorkspaceRoot: On,
  codexHome: Nn,
  canUseProjectlessThreads: xt
});

Kn = Gn === `~`;
Ke = a(C, H) === `projectless`;
fo = li === `worktree` ? so : Gn;

The footer then receives hideRunLocationDropdown: Zc. In the external footer chunk, that becomes hideModeDropdown, and the local/remote/worktree dropdown is rendered with:

<LocalRemoteDropdown
  composerMode={r}
  setComposerMode={a}
  ...
  hideModeDropdown={L}
  allowWorktree={!V && !g}
  ...
/>

Separately, inside local-remote-dropdown-DnABqdXS.js, the effective worktree option gate is:

Me = J && ee && I

Where:

• J means the current target has a git root
• ee is the passed allowWorktree prop
• I appears to be the relevant worktree feature/capability flag

The dropdown already has remote-aware labels:

K ? remoteWorktreeMode : worktreeMode
K ? remoteWorktreeTooltip : worktreeTooltip

So the problem does not appear to be missing remote-worktree UI strings or missing pending-worktree submit code. It looks like the remote-project new-thread composer is failing before that: the run-location dropdown is hidden by Zc, and/or allowWorktree is false in the footer path.

I locally verified this by creating a patched copy of the app and changing only:

- hideRunLocationDropdown: Zc
+ hideRunLocationDropdown: false

and:

- Me = J && ee && I
+ Me = J && I

That is not meant as a proposed production fix, just confirmation that the relevant UI gates are in this area. A proper fix should probably make the Zc/allowWorktree logic aware of selectedRemoteProjectPath / remoteConfig.currentHostId instead of treating the remote-project composer like the generic projectless case.

This was an issue for me, seems to be fixed in the latest update