Skip to content

fix: fork session now uses modal with title field#933

Open
tzercin wants to merge 3 commits into
preset-io:mainfrom
tzercin:fix-fork-session-empty-title
Open

fix: fork session now uses modal with title field#933
tzercin wants to merge 3 commits into
preset-io:mainfrom
tzercin:fix-fork-session-empty-title

Conversation

@tzercin
Copy link
Copy Markdown
Contributor

@tzercin tzercin commented Apr 7, 2026

Summary

Fixes the issue where forked sessions were created with empty titles. The fork functionality now uses a modal dialog (like spawn does) to collect both a title and prompt from users before creating the fork.

Changes

1. Fork now uses modal dialog (555b5ef)

  • Changed fork button to open ForkSpawnModal instead of directly using input value
  • Ensures users always provide a prompt when forking
  • Consistent UX with spawn workflow

2. Added dedicated title field (b813acb)

  • Added required Title input field to fork modal
  • Title is separate from the prompt (matches "Create New Session" UX)
  • Title flows through entire chain: UI → hooks → backend
  • Backend uses explicit title or falls back to first 100 chars of prompt
  • Updated description text: "Create a forked session" (was "sibling session")

Screenshots

Before: Fork button directly used input value (could be empty)
Forked sessions created without title, and empty content.
image

After: Modal with dedicated title and prompt fields
image

Benefits

  • ✅ Forked sessions always have meaningful titles
  • ✅ Consistent UX between fork and spawn
  • ✅ Built-in validation prevents empty prompts
  • ✅ Clear separation between title (display name) and prompt (agent task)

Files Changed

  • apps/agor-ui/src/components/ForkSpawnModal/ForkSpawnModal.tsx - Added title field
  • apps/agor-ui/src/components/SessionPanel/SessionPanel.tsx - Use modal for fork
  • apps/agor-ui/src/hooks/useSessionActions.ts - Pass title to backend
  • apps/agor-ui/src/contexts/AppActionsContext.tsx - Add title parameter
  • apps/agor-ui/src/App.tsx - Thread title through handler
  • apps/agor-daemon/src/index.ts - Accept title in fork endpoint
  • apps/agor-daemon/src/services/sessions.ts - Use title if provided

Test Plan

  • Fork modal opens when clicking fork button
  • Title field is required
  • Prompt field is required
  • Forked session created with correct title
  • Forked session receives prompt and begins execution
  • Modal description shows "forked session" text

🤖 Generated with Claude Code

tzercin and others added 3 commits April 6, 2026 13:54
The fork session button was directly calling onFork with the current input value,
which could be empty. This resulted in forked sessions having empty titles.

Changed fork to use ForkSpawnModal (like spawn does) to:
- Ensure users always provide a prompt when forking
- Maintain consistency with spawn workflow
- Validate prompt is non-empty before creating fork

Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
Users can now specify a separate title when forking a session,
distinct from the prompt. This aligns with the "Create New Session"
modal UX where title and prompt are separate fields.

Changes:
- Added title input field to ForkSpawnModal (for fork action)
- Thread title through fork chain: UI → hook → backend
- Backend fork method uses explicit title if provided
- Updated description text: "forked session" (was "sibling session")
- Title field is required to ensure non-empty session names

Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
Apply Biome formatter rules to fix CI lint errors:
- Split long function signatures across multiple lines
- Reformat ternary expressions for readability

Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
@mistercrunch
Copy link
Copy Markdown
Member

Oh interesting. Currently I'll type the prompt in the current sesh and quick-hit fork session, but i like the idea of having the title there. In its current form, does the modal carry what's in the prompt box into the modal?

Also, please test that current session configuration get respected/carried-forward.

Note that we could add a collapse that would show a subset of the agentic tool configuration, locked on the current tool.

Side note: I've been meaning to create a cross-tool forking option, like going from Claude to Codex, say "claude is having some trouble getting this right, Codex, can you give it a shot?". This would require some mechanism to "dump" the full session into the new tool to prime it. Some more thoughts about getting this right, and what the template might look like:

  • pre prompt: "You're continuing a conversation that started with {tool} {model} .... "
  • dump all the messages: "[USER] ... [AGENT] ... {loop}"
  • include tool calls/results?
  • do this "since last compaction" to avoid blowing up the context in the new session

Main reason why I haven't done it already is "spawning subsession" work just fine for that, where the parent session can fetch [only] the useful context from its session and prepare a prompt for the other tool. Works pretty nicely already, and if effectively a selective compaction if done right.

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

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants