Skip to content

fix(web): new-thread defaults ignored for remote environments#4276

Open
t3dotgg wants to merge 1 commit into
mainfrom
fix/new-thread-defaults-remote-envs
Open

fix(web): new-thread defaults ignored for remote environments#4276
t3dotgg wants to merge 1 commit into
mainfrom
fix/new-thread-defaults-remote-envs

Conversation

@t3dotgg

@t3dotgg t3dotgg commented Jul 22, 2026

Copy link
Copy Markdown
Member

Problem

Setting New threads → New worktree (and the nested "Start from origin" toggle) had no effect when creating threads on remote environments: new remote threads always started in local mode on the current branch/worktree.

Root cause: defaultThreadEnvMode / newWorktreesStartFromOrigin are server settings persisted in settings.json, and the settings UI only ever writes to the primary environment's settings (useUpdatePrimarySettings). But the code paths that seed new drafts read the setting from the target thread's environment:

  • useNewThreadHandlerserverConfigs.get(projectRef.environmentId)?.settings ?? DEFAULT_SERVER_SETTINGS
  • Sidebar's createThreadForProjectMember — same per-environment lookup
  • ChatView's env-mode toggle and start-from-origin resolution — useEnvironmentSettings(environmentId)

Since nothing can write these preferences onto a remote server's settings.json, remote environments always decoded the schema defaults (defaultThreadEnvMode: "local"), silently overriding the user's choice. Worse, with the sidebar's seed-context logic, the "local" default made new threads inherit the active thread's branch/worktree — hence "wrong branch every time".

Fix

Treat new-thread defaults as what they are — a user preference — and read them from the primary environment's settings (primaryServerSettingsAtom) in all three call sites. Remote environments no longer fall back to decoded defaults.

Verification

  • bun run typecheck (web) passes
  • vp test on Sidebar.logic.test.ts, chatThreadActions.test.ts, ChatView.logic.test.ts — 101 tests pass
  • lint clean (remaining warnings pre-existing, unrelated files)

🤖 Generated with Claude Code


Note

Low Risk
Targeted read-path change for draft seeding and env toggles; no auth or persistence changes, behavior aligns with where settings are already written.

Overview
New-thread defaults (defaultThreadEnvMode, Start from origin for worktrees) are user preferences stored only on the primary environment’s settings.json, but creation and composer flows were reading them from the target environment’s settings. Remote servers never get those values, so drafts always fell back to schema defaults (local mode / wrong branch).

The PR switches ChatView, Sidebar (createThreadForProjectMember), and useNewThreadHandler to use primaryServerSettingsAtom for those fields. Per-environment useServerConfigs / DEFAULT_SERVER_SETTINGS fallbacks are removed where they seeded new threads.

Reviewed by Cursor Bugbot for commit 65c9f07. Bugbot is set up for automated code reviews on this repo. Configure here.

Note

Fix new-thread defaults to use primary server settings for remote environments

When creating a new thread, defaultThreadEnvMode and newWorktreesStartFromOrigin were resolved from per-environment server configs or hardcoded defaults, causing remote environment settings to be ignored. This fix updates ChatView.tsx, Sidebar.tsx, and useHandleNewThread.ts to read these values from primaryServerSettingsAtom instead.

Macroscope summarized 65c9f07.

The "New threads" default (local vs. new worktree) and "start from
origin" are stored in the server-side settings.json, but the settings UI
only ever writes to the primary environment's settings. New-thread code
paths read the setting from the thread's own environment, so threads
created on remote environments always fell back to the decoded defaults
("local" mode on the current branch) no matter what the user picked.

Read the defaults from the primary server settings everywhere they seed
new drafts: useNewThreadHandler, the sidebar's per-project new-thread
seeding, and ChatView's env-mode/start-from-origin resolution.

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
@github-actions github-actions Bot added vouch:trusted PR author is trusted by repo permissions or the VOUCHED list. size:M 30-99 changed lines (additions + deletions). labels Jul 22, 2026
@coderabbitai

coderabbitai Bot commented Jul 22, 2026

Copy link
Copy Markdown

Important

Review skipped

Auto reviews are disabled on this repository. Please check the settings in the CodeRabbit UI or the .coderabbit.yaml file in this repository. To trigger a single review, invoke the @coderabbitai review command.

⚙️ Run configuration

Configuration used: Repository UI

Review profile: CHILL

Plan: Pro

Run ID: 34265066-c2e0-40fe-9c5e-4a1ad0220c88

You can disable this status message by setting the reviews.review_status to false in the CodeRabbit configuration file.

Use the checkbox below for a quick retry:

  • 🔍 Trigger review
✨ Finishing Touches
🧪 Generate unit tests (beta)
  • Create PR with unit tests
  • Commit unit tests in branch fix/new-thread-defaults-remote-envs

Comment @coderabbitai help to get the list of available commands.

@macroscopeapp

macroscopeapp Bot commented Jul 22, 2026

Copy link
Copy Markdown
Contributor

Approvability

Verdict: Approved

Straightforward bug fix that reads new-thread default settings from the primary environment (where the settings UI stores them) instead of from remote environments where they're never configured. Clear intent, limited scope, consistent changes across files.

You can customize Macroscope's approvability policy. Learn more.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

size:M 30-99 changed lines (additions + deletions). vouch:trusted PR author is trusted by repo permissions or the VOUCHED list.

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant