cli: default exec cwd to container workspace folder#80
Conversation
\`devcontainer exec\` left WorkingDir empty when --working-dir wasn't passed, falling back to the image's WORKDIR. For stock devcontainer base images those happen to coincide, but a custom Dockerfile with a different WORKDIR would land the exec'd command outside the project. Resolve already gives us cfg.ContainerWorkspaceFolder (the spec's workspace path inside the container); default to that when --working-dir is empty. --working-dir still overrides. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
|
No actionable comments were generated in the recent review. 🎉 ℹ️ Recent review info⚙️ Run configurationConfiguration used: Organization UI Review profile: CHILL Plan: Pro Run ID: 📒 Files selected for processing (1)
📝 WalkthroughWalkthroughThe ChangesExec Working Directory Default
Estimated code review effort🎯 2 (Simple) | ⏱️ ~8 minutes Poem
🚥 Pre-merge checks | ✅ 4 | ❌ 1❌ Failed checks (1 warning)
✅ Passed checks (4 passed)
✏️ Tip: You can configure your own custom pre-merge checks in the settings. ✨ Finishing Touches📝 Generate docstrings
🧪 Generate unit tests (beta)
Comment |
Summary
devcontainer execused to leaveWorkingDirempty when--working-dirwasn't passed, which made the runtime fall back to the image'sWORKDIR. For stock devcontainer base images those happen to coincide with the spec'scontainerWorkspaceFolder, but a custom Dockerfile with a differentWORKDIRwould land the exec'd command outside the project — surprising for users runningdevcontainer exec ls.Default to
cfg.ContainerWorkspaceFolderwhen--working-diris empty. The flag still overrides.Test plan
🤖 Generated with Claude Code
Summary by CodeRabbit
execcommand now defaults to the container workspace folder as the working directory when--working-diris not specified, providing more intuitive behavior for common use cases.