Skip to content

Conversation

@stevenvo
Copy link
Contributor

Summary

Makes new tab creation more intuitive by inheriting the current working directory from the active tab.

Problem

When creating a new tab (Cmd+T), it always starts in the home directory, requiring users to cd back to their project directory. This breaks workflow continuity.

Solution

  • Extract cmd:cwd from the active tab's first terminal block
  • Pass inherited cwd as metadata to the new tab's terminal block
  • Terminal starts in the same directory as the previous tab

Behavior

  • With active tab in /projects/myapp: New tab starts in /projects/myapp
  • No active tab or no cwd: Falls back to home directory (~)
  • Initial launch: Not affected (uses default behavior)

Implementation

  • Modified CreateTab in pkg/wcore/workspace.go
  • Reads active tab's block metadata for cmd:cwd
  • Merges inherited cwd into new tab's terminal block
  • Backward compatible (doesn't break existing tab creation)

Test Plan

  • cd to project directory
  • Press Cmd+T to create new tab
  • Verify pwd shows same directory
  • Test with no active tab (home directory)
  • Test initial app launch (unchanged)

🤖 Generated with Claude Code

@CLAassistant
Copy link

CLAassistant commented Dec 15, 2025

CLA assistant check
All committers have signed the CLA.

@chatgpt-codex-connector
Copy link

You have reached your Codex usage limits for code reviews. You can see your limits in the Codex usage dashboard.

@coderabbitai
Copy link
Contributor

coderabbitai bot commented Dec 15, 2025

Walkthrough

The CreateTab function in pkg/wcore/workspace.go has been refactored to optimize workspace handling and implement metadata inheritance. The function now pre-fetches the workspace once at the start and reuses it for tab name derivation, eliminating a redundant call. Additionally, when creating a new tab alongside an active tab that isn't part of an initial launch, the function extracts the CmdCwd meta value from the first block of the active tab and propagates this metadata to the first block of the new tab by merging it into the layout before application.

Estimated code review effort

🎯 3 (Moderate) | ⏱️ ~22 minutes

Pre-merge checks and finishing touches

✅ Passed checks (3 passed)
Check name Status Explanation
Title check ✅ Passed The title 'New tabs inherit working directory from active tab' directly and clearly summarizes the main change in the pull request.
Description check ✅ Passed The description is comprehensive and directly related to the changeset, covering the problem, solution, behavior, implementation details, and test plan.
Docstring Coverage ✅ Passed Docstring coverage is 100.00% which is sufficient. The required threshold is 80.00%.
✨ Finishing touches
  • 📝 Generate docstrings

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

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

When creating a new tab (Cmd+T), it now starts in the same directory
as the currently active tab, instead of always defaulting to home.

- Extract cmd:cwd from active tab's first block
- Pass inherited cwd to new tab's terminal block via metadata
- Only applies to user-created tabs (not initial launch)
- Falls back to home directory if no cwd found

- More intuitive workflow - stay in your project directory
- Reduces need to cd after creating new tabs
- Maintains context across tabs

🤖 Generated with [Claude Code](https://claude.com/claude-code)
@stevenvo stevenvo force-pushed the feature/new-tab-inherit-cwd branch from 2f42152 to e17fa7b Compare January 3, 2026 08:42
Copy link
Contributor

@coderabbitai coderabbitai bot left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Actionable comments posted: 0

🧹 Nitpick comments (1)
pkg/wcore/workspace.go (1)

228-228: Verify if storing cwd in both Tab.Meta and Block.Meta is intentional.

The inheritedMeta is passed to createTabObj, which stores it in tab.Meta (line 281). Then lines 243-249 merge the same metadata into the first block's Meta. This results in the cwd being stored at two levels: the tab and the block.

According to the PR description, the goal is to "pass cwd as metadata to the new tab's terminal block", which suggests the block's meta is the intended target. Please confirm whether storing it in both locations serves a specific purpose or if one is redundant.

Also note that createTabObj calls GetWorkspace again at line 271, which is now redundant since the workspace is already fetched at line 200.

🔎 Optional refactor to eliminate redundant GetWorkspace call

Consider passing the workspace to createTabObj instead of re-fetching it:

-func createTabObj(ctx context.Context, workspaceId string, name string, meta waveobj.MetaMapType) (*waveobj.Tab, error) {
-	ws, err := GetWorkspace(ctx, workspaceId)
-	if err != nil {
-		return nil, fmt.Errorf("workspace %s not found: %w", workspaceId, err)
-	}
+func createTabObj(ctx context.Context, ws *waveobj.Workspace, name string, meta waveobj.MetaMapType) (*waveobj.Tab, error) {

Then update the call site:

-	tab, err := createTabObj(ctx, workspaceId, tabName, inheritedMeta)
+	tab, err := createTabObj(ctx, ws, tabName, inheritedMeta)
📜 Review details

Configuration used: Repository UI

Review profile: CHILL

Plan: Pro

📥 Commits

Reviewing files that changed from the base of the PR and between a07e078 and e17fa7b.

📒 Files selected for processing (1)
  • pkg/wcore/workspace.go
🔇 Additional comments (3)
pkg/wcore/workspace.go (3)

200-207: LGTM: Good optimization by pre-fetching workspace.

The early workspace fetch improves error handling and eliminates a redundant call for tab name derivation. This is cleaner than the previous implementation.


241-251: LGTM: Block metadata merging logic is correct.

The implementation safely merges inherited metadata into the first block's Meta before applying the layout. The nil-check and iteration logic are appropriate.

Note: The potential redundancy with Tab.Meta was already flagged in the previous comment on line 228.


209-226: Relying on first block having CWD metadata without type validation.

The inheritance logic assumes activeTab.BlockIds[0] is a terminal block with MetaKey_CmdCwd set. However, there's no constraint preventing non-terminal blocks (preview, web, sysinfo) from being added as the first block. If a user creates a non-terminal block first, the inheritance silently fails without indication.

The DBGet errors are silently ignored, but this is acceptable since the subsequent nil checks gracefully handle both "not found" and error cases, falling back to no inheritance.

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