fix(create): resolve user-supplied Dockerfile path from CLI invocation cwd, not project root

[aidandaly24]

Description

Fixes a bug in the agentcore create wizard where a user-supplied Dockerfile path was resolved relative to the discovered project root (or <projectRoot>/<codeLocation> for BYO) instead of the directory the user invoked the CLI from. Per the issue reporter, this gave confusing "not found" errors like:

path working dir is here - /workplace/.../.github/harnesses/

…when the user expected the path to be resolved relative to their actual cwd (e.g. /workplace/.../.github/).

Root cause

Two compounding problems in the TUI:

1. GenerateWizardUI.tsx and AddAgentScreen.tsx both called basename(value) inside the PathInput.onSubmit handler, which silently discarded the directory component of the path before it ever reached the resolution logic in useAddAgent.ts. As a result, the if (dockerfile?.includes('/')) branch in handleCreatePath was effectively dead code — no user-entered path was ever copied.
2. The BYO PathInput set its basePath to resolve(project.projectRoot, byoConfig.codeLocation), so completion + validation operated relative to <projectRoot>/<codeLocation> (e.g. …/.github/harnesses/), which is exactly the bogus path the user saw in the error.
3. useAddAgent.handleCreatePath and handleByoPath resolved the source path with resolve(projectRoot, dockerfile), ignoring the user's actual cwd.

Fix

• Stop calling basename() in both wizard onSubmit handlers — pass the raw user input through.
• Set the BYO PathInput basePath to process.cwd() so completion + validation match where the user invoked the CLI (consistent with the GenerateWizardUI Dockerfile prompt and the existing policy --source flow).
• Extract a small, pure helper resolveUserDockerfile(value, cwd, fileExists?) in useAddAgent.ts that:
  • Returns no-op for undefined/empty.
  • Returns no-op for a bare filename (preserves the existing template-default semantics; the agent-env CDK schema also requires a filename, not a path).
  • Resolves anything else against process.cwd(), validates with existsSync, and instructs the caller to copy it into the agent / BYO code directory under just the basename.
• Refactor handleCreatePath and handleByoPath to call the new helper, eliminating duplication.

The detection condition value !== basename(value) also fixes a latent Windows bug where the previous value.includes('/') would miss \ separators.

The persisted spec value remains a basename, so the CDK constructs and downstream renderers/packagers/config-bundle generation are unaffected.

Related Issue

Closes #1128

Documentation PR

N/A — purely a CLI bug fix; no public API or documented behavior changes.

Type of Change

• Bug fix
• New feature
• Breaking change
• Documentation update
• Other (please describe):

Testing

How have you tested the change?

• I ran npm run test:unit and npm run test:integ
• I ran npm run typecheck
• I ran npm run lint
• If I modified src/assets/, I ran npm run test:update-snapshots and committed the updated snapshots

Targeted test runs

• src/cli/tui/screens/agent/__tests__/useAddAgent.test.ts (new) — 8/8 pass. Covers:
  • undefined / empty input → no-op
  • bare filename → preserved, never touches fs
  • relative path → resolved against cwd
  • nested relative path → basename extracted correctly
  • absolute path → honored as-is
  • missing file → ok: false, error mentions cwd-resolved path
  • regression for The path to dockerfile should be fixed to where the agentcore command was run #1128: does NOT resolve under projectRoot/codeLocation
• src/cli/tui/screens/generate/__tests__/useGenerateWizard.test.tsx — 37/37 pass (added a regression test that setDockerfile('./subdir/Dockerfile.dev') preserves the directory components).
• src/cli/tui/screens/agent/__tests__/computeByoSteps.test.ts — 4/4 pass (sanity check, unaffected).

Manual verification

1. From a sub-directory of a project (e.g. <projectRoot>/.github/), run agentcore create, choose a Container build, supply ./Dockerfile.dev → file is copied into the agent directory and the spec records dockerfile: "Dockerfile.dev".
2. Repeat for the BYO flow with subdir/Dockerfile.gpu and an absolute /tmp/Dockerfile.
3. Bare Dockerfile input still falls through to the template default (no copy), preserving existing UX.

Checklist

• I have read the CONTRIBUTING document
• I have added any necessary tests that prove my fix is effective or my feature works
• I have updated the documentation accordingly
• I have added an appropriate example to the documentation to outline the feature, or no new docs are needed
• My changes generate no new warnings
• Any dependent changes have been merged and published

---

By submitting this pull request, I confirm that you can use, modify, copy, and redistribute this contribution, under the
terms of your choice.

[github-actions]

Coverage Report

Status	Category	Percentage	Covered / Total
🔵	Lines	43.21%	9042 / 20922
🔵	Statements	42.49%	9600 / 22592
🔵	Functions	40.03%	1559 / 3894
🔵	Branches	40.03%	5818 / 14532

Generated in workflow #2592 for commit 17baa7e by the Vitest Coverage Report Action

[agentcore-cli-automation]

Nice, focused bug fix. The root-cause analysis in the PR description matches what I see on main — both wizards' onSubmit handlers were pre-stripping the directory before it reached handleCreatePath/handleByoPath, so the includes('/') branch was effectively dead code. Extracting resolveUserDockerfile into a pure helper and driving it off process.cwd() is the right shape.

I traced the flow end-to-end and I don't see anything that needs to change before merging:

• Empty-string handling is safe: the BYO onSubmit stores '', resolveUserDockerfile('') returns { copy: false }, and mapByoConfigToAgent/mapAddAgentConfigToGenerateConfig both omit falsy dockerfile from the spec (schema rejects '', so this matters).
• The basename()-based "bare filename" check correctly handles \ on Windows via path.win32.basename, fixing the latent bug called out in the description.
• The renderer's exclude = new Set(['Dockerfile']) branch in BaseRenderer.ts means that when the user supplies a path like ./Dockerfile.dev, the template's default Dockerfile is correctly excluded and the copied file takes its place. No duplicate Dockerfile ends up in the agent dir.
• Paths like ../Dockerfile end up persisted as the basename, which satisfies the strict schema regex in agent-env.ts.
• PathInput already does upfront existsSync validation against the same basePath (process.cwd()), so the ok: false branch in resolveUserDockerfile is mostly a defensive double-check — the "half-rendered agent on missing file" concern is not a practical regression.

No blocking comments — approving.

[aidandaly24]

Closing: duplicate from batch test run