feat: add post_start_command param to create_workspace tool - #23
Conversation
Allow callers to specify a shell command that runs in the dev container after the workspace starts, via a DevWorkspace postStart event. Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
|
Warning Review limit reached
Next review available in: 4 minutes Enable usage-based reviews in Billing to review now. Otherwise, wait until the next included review is available. How can I continue?After more reviews become available, a review can be triggered using the To avoid repeated limits, reduce automatic review volume by pausing incremental auto-reviews earlier, using label-based review opt-in, excluding WIP or generated PR titles, or requesting reviews manually when the PR is ready. If your team needs uninterrupted high-volume reviews, an organization admin can enable usage-based reviews. How do review limits work?CodeRabbit enforces per-developer PR review limits for each organization. Most developers receive the normal plan review availability. For paid Pro and Pro+ PR reviews, CodeRabbit uses adaptive limits for sustained high-volume activity. When a developer's recent PR review activity reaches the 95th percentile or higher among CodeRabbit users, additional reviews become available more gradually as earlier reviews age out of the rolling window. Please refer docs for additional details. Review details⚙️ Run configurationConfiguration used: defaults Review profile: CHILL Plan: Pro Run ID: 📒 Files selected for processing (5)
📝 WalkthroughWalkthroughThe ChangesPost-start command support
Estimated code review effort: 2 (Simple) | ~10 minutes Sequence Diagram(s)sequenceDiagram
participant create_workspace
participant createWorkspace
participant DevWorkspaceTemplate
create_workspace->>createWorkspace: pass post_start_command
createWorkspace->>DevWorkspaceTemplate: add post-start command
createWorkspace->>DevWorkspaceTemplate: wire postStart event
Possibly related PRs
Suggested reviewers: 🚥 Pre-merge checks | ✅ 5✅ Passed checks (5 passed)
✨ Finishing Touches🧪 Generate unit tests (beta)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
|
Image built: |
akurinnoy
left a comment
There was a problem hiding this comment.
Clean, focused change. The interaction between post_start_command and the tools parameter was the main thing to verify - the tool injector's buildJsonPatchOps correctly appends to existing commands/events arrays rather than replacing them, so there is no ordering issue.
One suggestion on testing: consider adding a combined test that sets both tools and post_start_command. The interaction is currently safe, but an explicit test would document this behavior and guard against future regressions if the template construction order changes.
Two minor points are called out as inline comments (whitespace input edge case, assignment vs. merge).
| .describe('Branch or revision to check out (requires repo_url)'), | ||
| post_start_command: z | ||
| .string() | ||
| .optional() |
There was a problem hiding this comment.
Consider adding a non-empty constraint here. The current .string().optional() passes a whitespace-only value like " " through to the guard in create-workspace.ts, which evaluates it as truthy and injects a blank command into the DevWorkspace.
A .trim().min(1) chain would reject the bad input at the schema level:
| .optional() | |
| post_start_command: z | |
| .string() | |
| .trim() | |
| .min(1) | |
| .optional() | |
| .describe('Shell command to run in the dev container after workspace starts'), |
Does it make sense to validate this at the Zod layer rather than in the implementation?
There was a problem hiding this comment.
Fixed. Added .trim().min(1) to the Zod schema — whitespace-only input is now rejected at validation. Also added a combined tools + post_start_command test as suggested in the top-level review.
| } | ||
|
|
||
| if (params.post_start_command) { | ||
| template.commands = [ |
There was a problem hiding this comment.
Nit: consider a merge pattern instead of assignment. The current code is safe today - nothing else sets template.commands before this point. But a future change that adds another command source above this block would cause silent data loss.
A small guard makes the intent explicit:
| template.commands = [ | |
| template.commands = [ | |
| ...(Array.isArray((template as any).commands) ? (template as any).commands : []), |
Not blocking - just flagging for awareness.
There was a problem hiding this comment.
Implemented. Using merge pattern for both commands and events — checks for existing arrays/objects before appending.
|
Image built: |
Summary
post_start_commandparameter to thecreate_workspaceMCP toolexeccommand andpostStartevent so the given shell command runs in thedevcontainer after workspace startupTest plan
npm run buildcompiles without errorsnpm test— all 142 tests pass (2 new)post_start_commandand verify the command runs on startup🤖 Generated with Claude Code
Summary by CodeRabbit