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
- Open a git repository in Kiro
- Have the agent read a file with
readFile (e.g. src/service.ts)
- Have the agent run
git checkout -B other-branch origin/other-branch via executeBash — this changes src/service.ts on disk
- 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
File tools return stale content after
git checkoutchanges files on diskDescription
When the agent uses
executeBashto rungit 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
strReplacesilently fails (the old string doesn't match the new file content), andreadFilereturns content from the previous branch.Steps to Reproduce
readFile(e.g.src/service.ts)git checkout -B other-branch origin/other-branchviaexecuteBash— this changessrc/service.tson diskreadFileExpected:
readFilereturns the content fromother-branchActual:
readFilereturns the content from the previous branch (stale cache)Impact
strReplacefails silently because the old string doesn't match the new file contentfsWritemay overwrite the correct branch content with stale datased,grep) for file operations after branch switches, defeating the purpose of dedicated file toolsWorkaround
Use shell commands for file reads and edits after any
git checkoutthat changes files on disk. Reading viacatinexecuteBashalways reflects the disk state.Environment
executeBash