fix: update remediation prompt to search ALL lockfiles across repository

[aivong-openhands]

Summary

Port changes from OpenHands/vulnerability-fixer#44 to the vulnerability remediation plugin.

Problem

The remediation agent was only updating lockfiles in the root directory, missing subdirectory lockfiles (e.g., enterprise/poetry.lock in the OpenHands repository).

This was reported in OpenHands/OpenHands#13371 where the PR fixed CVE vulnerabilities but missed updating the enterprise poetry lock.

Root Cause

The original prompt told the agent to "Locate the dependency file" (singular), causing it to only look at root-level files.

Solution

Updated create_remediation_prompt() to explicitly instruct the agent to:

1. Search the entire repository recursively for ALL dependency files using find commands
2. Update every matching file that contains the vulnerable package
3. Find ALL lockfiles in the repository, not just root-level ones
4. Navigate to each lockfile's directory and regenerate it with the correct tool version

Performance Optimization

The find commands now exclude common dependency and build directories to avoid wasting time:

• node_modules/ - npm/yarn/pnpm dependencies
• .venv/, venv/ - Python virtual environments
• vendor/ - Go/PHP vendor directories
• .git/ - Git internal directory
• __pycache__/ - Python bytecode cache
• dist/, build/ - Build output directories

Changes

• plugins/vulnerability-remediation/scripts/scan_and_remediate.py: Updated create_remediation_prompt() with recursive search and directory exclusions

[all-hands-bot]

Taste Rating: 🟡 Acceptable - Core fix addresses a real problem, but the PR description is corrupted and needs evidence.

CRITICAL ISSUES:
Your PR description is garbled (see line starting with "4. **Navigate to each lockfile..."). Fix before merge.

KEY INSIGHT: The fix correctly shifts from singular "the dependency file" to recursive search of all dependency files. This is the right engineering approach for a real bug, but execution needs polish.

[all-hands-bot]

🟠 Important - Robustness: These find + xargs + grep chains have an edge case. If find returns no results, xargs grep will hang waiting for stdin or fail depending on xargs implementation.

Better pattern:

find . \( -name node_modules ... \) -prune -o -name "pyproject.toml" -exec grep -l "{vuln.package_name}" {} + 2>/dev/null || true

The -exec ... + is more robust than piping to xargs, and || true prevents pipeline failures when no matches exist.

[all-hands-bot]

🟡 Suggestion - Pragmatism: This find command is cleaner since it doesn't need grep, but you're still building a long exclusion list. Consider if there's a simpler approach:

Could you leverage existing .gitignore patterns? Many repos already define what should be ignored. Alternatively, document why each exclusion is necessary so maintainers understand the tradeoffs.

Not blocking, but worth considering for the next iteration.

[all-hands-bot]

🟢 Good taste: The explicit cd to directory approach eliminates the complexity of trying to run package managers from arbitrary locations. Simple and correct.

[all-hands-bot]

🔴 CRITICAL - Missing Evidence: Your PR description claims to fix the subdirectory lockfile problem, but provides zero proof that this was tested.

Required before merge:

1. Add an Evidence section to the PR description
2. Show the actual output from running the remediation agent on a repo with subdirectory lockfiles (e.g., a test run showing both root and enterprise/poetry.lock being updated)
3. Include the agent conversation URL if this was developed/tested using OpenHands

Test output alone doesn't count - I need to see the real agent execution with this updated prompt actually finding and updating subdirectory files.

Also: Your PR description is corrupted starting at item 4. Fix that garbled text.

[all-hands-bot]

Taste Rating: 🟡 Acceptable

The core insight is correct: shifting from singular "the dependency file" to recursive search across ALL dependency files fixes a real bug. However, there are blocking issues that must be addressed before merge.

VERDICT: ❌ Needs rework - Fix the robustness issues and add evidence before merge.

KEY INSIGHT: The fix correctly identifies that monorepos have lockfiles in subdirectories, but the shell command patterns used to implement the search are fragile and will fail in edge cases.

[all-hands-bot]

🔴 CRITICAL - Missing Evidence: Your PR description claims this fixes subdirectory lockfiles (e.g., enterprise/poetry.lock in OpenHands), but you provide ZERO proof that you actually tested this.

Required before merge:

Add an Evidence section to the PR description showing:

1. The exact command you ran to test the remediation agent
2. Terminal output demonstrating that it found and updated a subdirectory lockfile (not just root-level)
3. A link to the agent conversation if this work was done via OpenHands Cloud

Without evidence, we have no confidence this actually works. Test output alone does not count - show the real runtime behavior end-to-end.

[aivong-openhands]

vulnerability fixer correctly regenerated the enterprise poetry lock in OpenHands/OpenHands#13405

[all-hands-bot]

🟢 Good taste: The explicit cd to each lockfile's directory is simple and correct. No need to deal with relative paths or figure out how to invoke package managers from arbitrary locations. This is the right engineering choice.

[all-hands-bot]

🟡 Suggestion - Pragmatism: This exclusion list works, but it's incomplete and will grow over time. Consider:

1. Could you leverage .gitignore patterns that repos already maintain?
2. Is there a standard "ignore build/dependency directories" pattern you can reuse?

That said, the current approach is pragmatic and covers 95% of real cases. Don't over-engineer this unless you have evidence of repos where it fails. Perfect is the enemy of good enough.