fix(import): escape triple-quotes in collaborationInstruction

[padmak30]

Description

escape triple-quotes in collaborationInstruction

[github-actions]

Package Tarball

aws-agentcore-0.14.1.tgz

How to install

gh release download pr-1329-tarball --repo aws/agentcore-cli --pattern "*.tgz" --dir /tmp/pr-tarball
npm install -g /tmp/pr-tarball/aws-agentcore-0.14.1.tgz

[agentcore-cli-automation]

Thanks for catching the docstring injection — the security fix is correct in spirit, but the way the two escape helpers are chained introduces a new bug for any input containing backslashes.

escapePySingleQuote already does \\ → \\\\, and escapePyTripleQuote does \\ → \\\\ again. Composing them therefore quadruples every backslash.

I verified by simulating in Python with the same code paths:

User input:                C:\path\to\file
After this PR (chained):   C:\\\\path\\\\to\\\\file   (in source) → C:\\path\\to\\file (at runtime)
Before this PR:            C:\\path\\to\\file         (in source) → C:\path\to\file   (at runtime, correct)

So a collaborationInstruction containing backslashes (Windows paths, regex patterns, JSON-escaped strings, etc.) will be silently corrupted in the generated docstring after this change.

A couple of options to fix:

• Apply only escapePyTripleQuote. The value lives in a triple-quoted docstring; the surrounding '…' is just decorative text, not Python syntax. Escaping """ and backslashes is sufficient — ' doesn't need escaping inside a triple-quoted string.
• Compose them without re-escaping backslashes. E.g. introduce a single helper that escapes \, then ', then """, then \n in one pass, or strip the redundant \\ → \\\\ step from one of the helpers when chained.

Either way, please add a test with a backslash-bearing payload (e.g. 'C:\\path\\to\\file' or 'pattern: \\d+') that asserts the runtime docstring (or at least the emitted source) preserves the original backslash count, so this regression is caught.

A nit on the existing test: the negative assertion not.toMatch(/""".*"""\s*"""/s) is quite weak. Asserting that mainPyContent still parses as valid Python (or at least that the dangerous tokens like import subprocess don't appear at top-level / outside the docstring) would give a stronger guarantee that injection is actually neutralized.

[github-actions]

Coverage Report

Status	Category	Percentage	Covered / Total
🔵	Lines	43.87%	9346 / 21299
🔵	Statements	43.12%	9917 / 22996
🔵	Functions	40.38%	1610 / 3987
🔵	Branches	40.61%	6082 / 14976

Generated in workflow #3171 for commit d7ff8a1 by the Vitest Coverage Report Action

[agentcore-devx-automation]

Claude Security Review: no high-confidence findings. (run)

[agentcore-devx-automation]

Claude Security Review: no high-confidence findings. (run)