Skip to content

File tools return stale content after git checkout changes files on disk #8035

Description

@renfeng

File tools return stale content after git checkout changes files on disk

Description

When the agent uses executeBash to run git checkout -B <branch> origin/<branch> (switching to a different branch), the file tools (readFile, strReplace, fsWrite) continue to read and write against the pre-checkout file content. Shell commands (grep, sed, cat) correctly see the post-checkout content.

This means strReplace silently fails (the old string doesn't match the new file content), and readFile returns content from the previous branch.

Steps to Reproduce

  1. Open a git repository in Kiro
  2. Have the agent read a file with readFile (e.g. src/service.ts)
  3. Have the agent run git checkout -B other-branch origin/other-branch via executeBash — this changes src/service.ts on disk
  4. Have the agent read the same file again with readFile

Expected: readFile returns the content from other-branch
Actual: readFile returns the content from the previous branch (stale cache)

Impact

  • strReplace fails silently because the old string doesn't match the new file content
  • fsWrite may overwrite the correct branch content with stale data
  • The agent must fall back to shell commands (sed, grep) for file operations after branch switches, defeating the purpose of dedicated file tools

Workaround

Use shell commands for file reads and edits after any git checkout that changes files on disk. Reading via cat in executeBash always reflects the disk state.

Environment

  • Kiro on macOS (darwin)
  • Multi-root workspace with multiple git repositories
  • Observed during a session where the agent switched branches on a workspace folder repo via executeBash

Metadata

Metadata

Assignees

No one assigned

    Labels

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions