`replace_string_in_file` reports success but doesn't persist changes
Nobody has claimed this yet.
Assessment
- Difficulty
- 4/5
- Estimated time
- 3-5 days
- Newbie friendliness
- 38/100
Research direction
Start by reproducing replace_string_in_file on the affected Swift files in an Xcode workspace, then compare its on-disk result with insert_edit_into_file. Trace the replace_string_in_file entry point and verify that successful edits persist and that failed writes or unmatched replacements report an error rather than success.
Written by the indexing model from the issue text.
Description
Summary
The replace_string_in_file editing tool consistently reports successful edits but fails to write changes to disk, requiring escalation to insert_edit_into_file. This silent failure wastes significant time and breaks trust in the tool.
Core Problem
What happens:
- Tool reports: "✅ The following files were successfully edited"
- File on disk remains unchanged (verified via
grep,sed) - Compilation errors persist for missing code
- No error message or warning given
Scale: 15-20 failed operations across multiple files in a single session
Reproduction Steps
Attempt 1: Basic Replace
// Trying to add property to struct
OLD: public var existingProperty: Type
NEW: public var existingProperty: Type
public var newProperty: NewType // ← Should be added
Result: Tool reports success, property not added
Attempt 2: More Context
Added 5+ lines of surrounding context for uniqueness
Result: Same false success, no file modification
Attempt 3: Smaller Edits
Broke into multiple atomic replace_string_in_file calls
Result: All reported success, none persisted
Attempt 4: Different Tool (Workaround)
Switched to insert_edit_into_file with full code block
Result: ✅ SUCCESS - File actually modified
Examples of Silent Failures
Example 1: Adding Property
// Attempting to add to line 21:
public var radius: Double
public var newConfig: Config // ← Not added despite success report
public var model: ModelType
Verified via: grep "newConfig" File.swift (no results)
Example 2: Renaming Class
OLD: public class OldName {
NEW: public class NewName {
Verified via: grep "class NewName" (empty - still OldName)
Example 3: Updating Parameters
Changed type in 4 method signatures
All 4 reported success, none actually changed
Verified via: grep "OldType" (still 4 occurrences)
File Context
Common factors:
- Xcode workspace (
.xcworkspace) - Swift files (
.swift) - Some had extended attributes (
@flag) - Files actively loaded in Xcode
- 100-30,000 lines
- Complex Swift (generics, protocols, async/await)
Impact
- Time lost: 60-80 minutes debugging
- Trust: Tool reliability undermined
- Workflow: Required terminal verification for every edit
- Escalation: Eventually abandoned
replace_string_in_fileentirely
Expected vs Actual Behavior
| Expected | Actual |
|---|---|
| File modified on disk | File unchanged |
| Compilation reflects changes | Compilation errors persist |
| Subsequent reads show new content | Old content remains |
| OR: Error reported if write fails | False success reported |
Successful Workaround
# 1. Detect failure with terminal:
grep "expected_symbol" file.swift # (no output)
sed -n 'line,linep' file.swift # Shows old code
# 2. Use insert_edit_into_file instead:
# - Provide complete code block
# - Use // ...existing code... comments
# - Tool writes successfully
# 3. Verify after edit:
grep "expected_symbol" file.swift # Now found
Potential Causes
- File caching - Editor cache not flushed
- Xcode locks - Files locked by IDE
- Extended attributes -
@flag preventing writes - Path resolution - Writing to wrong location
- Silent match failure - Can't find string, reports success anyway
Recommended Fixes
- Verify writes - Read file back after write to confirm
- Report actual errors - Show permission/lock failures
- Flush buffers - Explicitly sync to disk before success
- Detect locks - Check if Xcode has file locked
- Auto-fallback - Suggest
insert_edit_into_fileon failure
Evidence
# Tool says success:
✅ The following files were successfully edited: /path/to/File.swift
# Reality check:
$ grep "newProperty" File.swift
# (no output - property was NOT added)
$ sed -n '19,23p' File.swift
public var oldProperty: Type
public var anotherOld: Type
# (missing newProperty that should be between them)
Reproducibility
- Frequency: 100% for affected files
- Pattern: Consistent across multiple file types/sizes
- Workaround:
insert_edit_into_filealways worked
Key Observation
The fact that insert_edit_into_file works reliably suggests this is a replace_string_in_file-specific issue, not a general file writing problem.
Priority: High - Core functionality broken
Request: Investigate silent failures in Xcode workspace context with Swift files
- Dominant language
- Swift
- Stars
- 6.3k
- Forks
- 2k
- Avg merge
- 3d 21h
- Merged PRs (30d)
- 2
Contributor guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
More from github/CopilotForXcode
-
Difficulty 1/5 Under an hour Newbie friendliness 85/100
github/CopilotForXcode#181 · 2 reactions ·
-
Add ability to attach Copilot window only to Xcode projects/workspaces, ignoring standalone files Open
Difficulty 3/5 1-2 days Newbie friendliness 68/100
github/CopilotForXcode#945 ·
-
Difficulty 2/5 1-3 hours Newbie friendliness 35/100
github/CopilotForXcode#943 ·
-
Difficulty 5/5 Over a week Newbie friendliness 10/100
github/CopilotForXcode#936 · 2 comments ·
-
Difficulty 5/5 Over a week Newbie friendliness 10/100
github/CopilotForXcode#934 ·
All issues in github/CopilotForXcode
Similar issues
-
area:dictation documentation P2
Difficulty 2/5 1-3 hours Newbie friendliness 78/100
uttrflow/uttrflow-swift#1180 ·
-
Difficulty 2/5 1-3 hours Newbie friendliness 78/100
-
Difficulty 2/5 1-3 hours Newbie friendliness 84/100
OneBusAway/onebusaway-ios#1451 ·
-
enhancement
Difficulty 2/5 1-3 hours Newbie friendliness 68/100