Subagent does not inherit parent's current working directory, breaking git worktree + subagent workflows

Open
#1,931 2 comments 0 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

Assessment

Difficulty
4/5
Estimated time
3-5 days
Newbie friendliness
38/100
Issue type
Bug
Clarity
Mostly clear
Activity status
Quiet
Tech stack
git, python
Domain
cli

Research direction

Start by tracing work-directory initialization and subagent copying in src/kimi_cli/soul/agent.py, then inspect Agent.Params in src/kimi_cli/tools/agent/init.py and SubagentBuilder in src/kimi_cli/subagents/builder.py. Determine and document the chosen work-directory behavior, add coverage for dispatching after entering a worktree or subdirectory, and verify file tools use the intended directory.

Written by the indexing model from the issue text.

Description

Problem Summary

When a root agent uses Shell to cd into a git worktree directory (or any subdirectory) and then dispatches a subagent via the Agent tool, the subagent continues to operate from the original root working directory, not the directory the parent agent has navigated to. This breaks workflows that rely on git worktree isolation combined with subagent delegation.

Concrete Example

Consider a common workflow from the "superpowers" skill ecosystem (e.g., using-git-worktrees + subagent-driven-development):

  1. Root agent creates a git worktree: git worktree add .worktrees/feature-x -b feature-x
  2. Root agent changes into the worktree: cd .worktrees/feature-x (via Shell tool)
  3. Root agent dispatches an implementer subagent to write code in the worktree
  4. Subagent writes files to the original project root instead of .worktrees/feature-x

The worktree isolation is completely bypassed because the subagent does not share the parent agent's current working directory context.

Root Cause Analysis

After reading the source code, I identified the exact mechanism:

1. KIMI_WORK_DIR is fixed at root runtime creation

In src/kimi_cli/soul/agent.py (line 316-319):

builtin_args=BuiltinSystemPromptArgs(
    KIMI_NOW=datetime.now().astimezone().isoformat(),
    KIMI_WORK_DIR=session.work_dir,      # <-- set once, never changes
    KIMI_WORK_DIR_LS=ls_output,
    ...
)
2. Subagent inherits the same builtin_args object

In src/kimi_cli/soul/agent.py (line 349-379), copy_for_subagent():

def copy_for_subagent(self, *, agent_id: str, subagent_type: str, llm_override=None) -> Runtime:
    return Runtime(
        ...
        builtin_args=self.builtin_args,    # <-- same object, same KIMI_WORK_DIR
        ...
    )
3. File tools use KIMI_WORK_DIR as their base

All file tools (ReadFile, WriteFile, Glob, etc.) read self._work_dir = runtime.builtin_args.KIMI_WORK_DIR at initialization.

4. Shell cd does not update session.work_dir

The Shell tool launches a new subprocess for each call. Even if the command is cd some/dir, this only affects that subprocess. It does not update session.work_dir or builtin_args.KIMI_WORK_DIR.

Impact

This makes the following patterns impossible to implement correctly:

  • Git worktree + subagent workflows: Agents cannot delegate work to subagents inside an isolated worktree.
  • Monorepo subproject delegation: A root agent cannot cd into a subpackage and dispatch a subagent to work there.
  • Any skill ecosystem that assumes cwd inheritance: Skills ported from Claude Code (which appears to handle this differently) silently fail.

Proposed Solutions

I would prefer not to patch every skill's prompt templates to pass absolute paths. That is fragile and leaks platform details into user-level skills. Instead, here are two architectural approaches:

Option A: Add work_dir parameter to the Agent tool

Allow the parent agent to explicitly set the subagent's working directory when dispatching:

class Params(BaseModel):
    ...
    work_dir: str | None = Field(
        default=None,
        description="Optional working directory for the subagent. Defaults to the current session's work_dir.",
    )

When work_dir is provided, SubagentBuilder.build_builtin_instance() would create a copy of builtin_args with the overridden KIMI_WORK_DIR.

Pros: Explicit, backward-compatible, gives full control to the parent agent.
Cons: Parent agent must know and pass the path.

Option B: Track per-agent current working directory

Introduce a mutable current_work_dir on the Runtime (or Session) that is updated when the agent successfully executes a cd command via Shell. Subagents inherit this value instead of the root KIMI_WORK_DIR.

This could work by:

  1. Parsing the Shell command to detect cd (or similar directory changes)
  2. Updating runtime.current_work_dir after successful execution
  3. copy_for_subagent() using current_work_dir for the new subagent's KIMI_WORK_DIR

Pros: Transparent, matches user intuition ("I cd'd there, so subagents should be there too").
Cons: More complex, requires parsing shell commands, platform-specific edge cases.

Option C: Hybrid — work_dir param + auto-detect from shell history

Provide the work_dir parameter (Option A) as the primary mechanism. As a convenience, if work_dir is not provided and the parent agent's last Shell call was a cd command, auto-populate it.

My recommendation: Option A is the cleanest. It is explicit, predictable, and does not require heuristics. Skills like using-git-worktrees can simply record the worktree absolute path after creation and pass it to every subagent dispatch.

Environment

  • kimi-cli version: 1.36.0
  • OS: Windows 11 (also reproducible on macOS/Linux)
  • Shell: PowerShell 5.1 / bash

Related Code Locations

  • src/kimi_cli/soul/agent.py:316-319KIMI_WORK_DIR initialization
  • src/kimi_cli/soul/agent.py:349-379copy_for_subagent()
  • src/kimi_cli/tools/agent/__init__.py:21-63Agent tool Params
  • src/kimi_cli/subagents/builder.py:12-35SubagentBuilder.build_builtin_instance()

Happy to provide more context or test a PR if helpful!

Dominant language
Python
Stars
11.4k
Forks
1.3k
Avg merge
9h 47m
Merged PRs (30d)
2

Contributor guide

Open the contributing guide

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

More from MoonshotAI/kimi-cli

All issues in MoonshotAI/kimi-cli

Similar issues

More Python issues

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.