Skip to content

feat: add post_start_command param to create_workspace tool - #23

Merged
tolusha merged 3 commits into
mainfrom
feat/create-workspace-post-start-command
Jul 15, 2026
Merged

feat: add post_start_command param to create_workspace tool#23
tolusha merged 3 commits into
mainfrom
feat/create-workspace-post-start-command

Conversation

@tolusha

@tolusha tolusha commented Jul 15, 2026

Copy link
Copy Markdown
Contributor

Summary

  • Adds an optional post_start_command parameter to the create_workspace MCP tool
  • When provided, injects a DevWorkspace exec command and postStart event so the given shell command runs in the dev container after workspace startup
  • Includes tests verifying the command/event are added when the param is set and absent when omitted

Test plan

  • npm run build compiles without errors
  • npm test — all 142 tests pass (2 new)
  • Manually create a workspace with post_start_command and verify the command runs on startup

🤖 Generated with Claude Code

Summary by CodeRabbit

  • New Features
    • Added an optional post-start command when creating a workspace.
    • Commands run automatically in the development container after the workspace starts.
  • Bug Fixes
    • Preserved workspace behavior when no post-start command is provided.
  • Tests
    • Added coverage for configured and omitted post-start commands.

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>
@tolusha
tolusha requested a review from akurinnoy as a code owner July 15, 2026 08:02
@coderabbitai

coderabbitai Bot commented Jul 15, 2026

Copy link
Copy Markdown

Review Change Stack

Warning

Review limit reached

@tolusha, you've reached your PR review limit, so we couldn't start this review.

Next review available in: 4 minutes

Enable usage-based reviews in Billing to review now. Otherwise, wait until the next included review is available.
You're only billed for reviews past your plan's rate limits ($0.25/file).

How can I continue?

After more reviews become available, a review can be triggered using the @coderabbitai review command as a PR comment. Alternatively, push new commits to this PR.

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 configuration

Configuration used: defaults

Review profile: CHILL

Plan: Pro

Run ID: ac0a0219-6e25-4a44-ae9d-966fbfb00596

📥 Commits

Reviewing files that changed from the base of the PR and between 33fb4a7 and 736d07d.

📒 Files selected for processing (5)
  • docs/superpowers/plans/2026-07-07-create-workspace-repo-clone.md
  • docs/superpowers/specs/2026-07-07-create-workspace-repo-clone-design.md
  • src/tools.ts
  • src/tools/create-workspace.ts
  • tests/tools/create-workspace.test.ts
📝 Walkthrough

Walkthrough

The create_workspace tool accepts an optional post_start_command, forwards it to createWorkspace, and conditionally adds a post-start command and postStart event to the DevWorkspace template. Tests cover both configured and omitted commands.

Changes

Post-start command support

Layer / File(s) Summary
Input contract and tool wiring
src/tools.ts, src/tools/create-workspace.ts
The tool schema and CreateWorkspaceParams accept post_start_command, and the handler forwards it to createWorkspace.
Workspace template event wiring
src/tools/create-workspace.ts, tests/tools/create-workspace.test.ts
Configured commands are added to the dev component with postStart event wiring; tests verify configured and omitted command behavior.

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
Loading

Possibly related PRs

Suggested reviewers: akurinnoy

🚥 Pre-merge checks | ✅ 5
✅ Passed checks (5 passed)
Check name Status Explanation
Description Check ✅ Passed Check skipped - CodeRabbit’s high-level summary is enabled.
Title check ✅ Passed The title clearly states the main change: adding a post_start_command parameter to the create_workspace tool.
Docstring Coverage ✅ Passed No functions found in the changed files to evaluate docstring coverage. Skipping docstring coverage check.
Linked Issues check ✅ Passed Check skipped because no linked issues were found for this pull request.
Out of Scope Changes check ✅ Passed Check skipped because no linked issues were found for this pull request.
✨ Finishing Touches
🧪 Generate unit tests (beta)
  • Create PR with unit tests
  • Commit unit tests in branch feat/create-workspace-post-start-command

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.

❤️ Share

Comment @coderabbitai help to get the list of available commands.

@github-actions

Copy link
Copy Markdown

Image built: quay.io/che-incubator/che-mcp-server:pr-23

@akurinnoy akurinnoy left a comment

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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).

Comment thread src/tools.ts
.describe('Branch or revision to check out (requires repo_url)'),
post_start_command: z
.string()
.optional()

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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:

Suggested change
.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?

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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 = [

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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:

Suggested change
template.commands = [
template.commands = [
...(Array.isArray((template as any).commands) ? (template as any).commands : []),

Not blocking - just flagging for awareness.

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Implemented. Using merge pattern for both commands and events — checks for existing arrays/objects before appending.

tolusha added 2 commits July 15, 2026 15:24
Signed-off-by: Anatolii Bazko <abazko@redhat.com>
Signed-off-by: Anatolii Bazko <abazko@redhat.com>
@github-actions

Copy link
Copy Markdown

Image built: quay.io/che-incubator/che-mcp-server:pr-23

@tolusha
tolusha merged commit 8ec34d0 into main Jul 15, 2026
3 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants