allow using a TokioCommandWrap for TokioChildProcess::new closes #243 by lucasfernog-crabnebula · Pull Request #245 · modelcontextprotocol/rust-sdk

lucasfernog-crabnebula · 2025-06-04T16:17:09Z

Motivation and Context

we need to be able to set KillOnDrop and most importantly CreationFlags for the process spawned - we're now using process-wrap so we need to expose that interface

see https://docs.rs/process-wrap/latest/process_wrap/#killondrop-and-creationflags

How Has This Been Tested?

I'm working on an app that relies on CreationFlags - so i just tested it on Windows :)

Breaking Changes

TokioCommandWrap implements Fromtokio::process::Command so this is not a breaking change, but also downstream users have more control over flags such as KillOnDrop and CreationFlags

Types of changes

Bug fix (non-breaking change which fixes an issue)
New feature (non-breaking change which adds functionality)
Breaking change (fix or feature that would cause existing functionality to change)
Documentation update

Checklist

I have read the MCP Documentation
My code follows the repository's style guidelines
New and existing tests pass locally
I have added appropriate error handling
I have added or updated documentation as needed

Additional context

…lcontextprotocol#243 TokioCommandWrap implements From<tokio::process::Command> so this is not a breaking change, but also downstream users have more control over flags such as KillOnDrop and CreationFlags see https://docs.rs/process-wrap/latest/process_wrap/#killondrop-and-creationflags

jokemanfire · 2025-06-07T02:38:11Z

- .stdin(std::process::Stdio::piped())
+ pub fn new(command: impl Into<TokioCommandWrap>) -> std::io::Result<Self> {
+ let mut command_wrap = command.into();
+ command_wrap


let mut command_wrap = command.into(); command_wrap .command_mut() .stdin(std::process::Stdio::piped()) .stdout(std::process::Stdio::piped());

…lcontextprotocol#243 (modelcontextprotocol#245) * allow using a TokioCommandWrap for TokioChildProcess::new closesmodelcontextprotocol#243 TokioCommandWrap implements From<tokio::process::Command> so this is not a breaking change, but also downstream users have more control over flags such as KillOnDrop and CreationFlags see https://docs.rs/process-wrap/latest/process_wrap/#killondrop-and-creationflags

lucasfernog-crabnebula · 2025-06-04T16:17:09Z

Motivation and Context

we need to be able to set KillOnDrop and most importantly CreationFlags for the process spawned - we're now using process-wrap so we need to expose that interface

see https://docs.rs/process-wrap/latest/process_wrap/#killondrop-and-creationflags

How Has This Been Tested?

I'm working on an app that relies on CreationFlags - so i just tested it on Windows :)

Breaking Changes

TokioCommandWrap implements Fromtokio::process::Command so this is not a breaking change, but also downstream users have more control over flags such as KillOnDrop and CreationFlags

Types of changes

Bug fix (non-breaking change which fixes an issue)
New feature (non-breaking change which adds functionality)
Breaking change (fix or feature that would cause existing functionality to change)
Documentation update

Checklist

I have read the MCP Documentation
My code follows the repository's style guidelines
New and existing tests pass locally
I have added appropriate error handling
I have added or updated documentation as needed

Additional context

…lcontextprotocol#243 TokioCommandWrap implements From<tokio::process::Command> so this is not a breaking change, but also downstream users have more control over flags such as KillOnDrop and CreationFlags see https://docs.rs/process-wrap/latest/process_wrap/#killondrop-and-creationflags

jokemanfire · 2025-06-07T02:38:11Z

- .stdin(std::process::Stdio::piped())
+ pub fn new(command: impl Into<TokioCommandWrap>) -> std::io::Result<Self> {
+ let mut command_wrap = command.into();
+ command_wrap


let mut command_wrap = command.into(); command_wrap .command_mut() .stdin(std::process::Stdio::piped()) .stdout(std::process::Stdio::piped());

…lcontextprotocol#243 (modelcontextprotocol#245) * allow using a TokioCommandWrap for TokioChildProcess::new closesmodelcontextprotocol#243 TokioCommandWrap implements From<tokio::process::Command> so this is not a breaking change, but also downstream users have more control over flags such as KillOnDrop and CreationFlags see https://docs.rs/process-wrap/latest/process_wrap/#killondrop-and-creationflags

lucasfernog-crabnebula · 2025-06-04T16:17:09Z

Motivation and Context

we need to be able to set KillOnDrop and most importantly CreationFlags for the process spawned - we're now using process-wrap so we need to expose that interface

see https://docs.rs/process-wrap/latest/process_wrap/#killondrop-and-creationflags

How Has This Been Tested?

I'm working on an app that relies on CreationFlags - so i just tested it on Windows :)

Breaking Changes

TokioCommandWrap implements Fromtokio::process::Command so this is not a breaking change, but also downstream users have more control over flags such as KillOnDrop and CreationFlags

Types of changes

Bug fix (non-breaking change which fixes an issue)
New feature (non-breaking change which adds functionality)
Breaking change (fix or feature that would cause existing functionality to change)
Documentation update

Checklist

I have read the MCP Documentation
My code follows the repository's style guidelines
New and existing tests pass locally
I have added appropriate error handling
I have added or updated documentation as needed

Additional context

…lcontextprotocol#243 TokioCommandWrap implements From<tokio::process::Command> so this is not a breaking change, but also downstream users have more control over flags such as KillOnDrop and CreationFlags see https://docs.rs/process-wrap/latest/process_wrap/#killondrop-and-creationflags

jokemanfire · 2025-06-07T02:38:11Z

- .stdin(std::process::Stdio::piped())
+ pub fn new(command: impl Into<TokioCommandWrap>) -> std::io::Result<Self> {
+ let mut command_wrap = command.into();
+ command_wrap


let mut command_wrap = command.into(); command_wrap .command_mut() .stdin(std::process::Stdio::piped()) .stdout(std::process::Stdio::piped());

…lcontextprotocol#243 (modelcontextprotocol#245) * allow using a TokioCommandWrap for TokioChildProcess::new closesmodelcontextprotocol#243 TokioCommandWrap implements From<tokio::process::Command> so this is not a breaking change, but also downstream users have more control over flags such as KillOnDrop and CreationFlags see https://docs.rs/process-wrap/latest/process_wrap/#killondrop-and-creationflags

lucasfernog-crabnebula · 2025-06-04T16:17:09Z

Motivation and Context

we need to be able to set KillOnDrop and most importantly CreationFlags for the process spawned - we're now using process-wrap so we need to expose that interface

see https://docs.rs/process-wrap/latest/process_wrap/#killondrop-and-creationflags

How Has This Been Tested?

I'm working on an app that relies on CreationFlags - so i just tested it on Windows :)

Breaking Changes

TokioCommandWrap implements Fromtokio::process::Command so this is not a breaking change, but also downstream users have more control over flags such as KillOnDrop and CreationFlags

Types of changes

Bug fix (non-breaking change which fixes an issue)
New feature (non-breaking change which adds functionality)
Breaking change (fix or feature that would cause existing functionality to change)
Documentation update

Checklist

I have read the MCP Documentation
My code follows the repository's style guidelines
New and existing tests pass locally
I have added appropriate error handling
I have added or updated documentation as needed

Additional context

…lcontextprotocol#243 TokioCommandWrap implements From<tokio::process::Command> so this is not a breaking change, but also downstream users have more control over flags such as KillOnDrop and CreationFlags see https://docs.rs/process-wrap/latest/process_wrap/#killondrop-and-creationflags

jokemanfire · 2025-06-07T02:38:11Z

- .stdin(std::process::Stdio::piped())
+ pub fn new(command: impl Into<TokioCommandWrap>) -> std::io::Result<Self> {
+ let mut command_wrap = command.into();
+ command_wrap


let mut command_wrap = command.into(); command_wrap .command_mut() .stdin(std::process::Stdio::piped()) .stdout(std::process::Stdio::piped());

…lcontextprotocol#243 (modelcontextprotocol#245) * allow using a TokioCommandWrap for TokioChildProcess::new closesmodelcontextprotocol#243 TokioCommandWrap implements From<tokio::process::Command> so this is not a breaking change, but also downstream users have more control over flags such as KillOnDrop and CreationFlags see https://docs.rs/process-wrap/latest/process_wrap/#killondrop-and-creationflags

lucasfernog-crabnebula · 2025-06-04T16:17:09Z

Motivation and Context

we need to be able to set KillOnDrop and most importantly CreationFlags for the process spawned - we're now using process-wrap so we need to expose that interface

see https://docs.rs/process-wrap/latest/process_wrap/#killondrop-and-creationflags

How Has This Been Tested?

I'm working on an app that relies on CreationFlags - so i just tested it on Windows :)

Breaking Changes

TokioCommandWrap implements Fromtokio::process::Command so this is not a breaking change, but also downstream users have more control over flags such as KillOnDrop and CreationFlags

Types of changes

Bug fix (non-breaking change which fixes an issue)
New feature (non-breaking change which adds functionality)
Breaking change (fix or feature that would cause existing functionality to change)
Documentation update

Checklist

I have read the MCP Documentation
My code follows the repository's style guidelines
New and existing tests pass locally
I have added appropriate error handling
I have added or updated documentation as needed

Additional context

…lcontextprotocol#243 TokioCommandWrap implements From<tokio::process::Command> so this is not a breaking change, but also downstream users have more control over flags such as KillOnDrop and CreationFlags see https://docs.rs/process-wrap/latest/process_wrap/#killondrop-and-creationflags

jokemanfire · 2025-06-07T02:38:11Z

- .stdin(std::process::Stdio::piped())
+ pub fn new(command: impl Into<TokioCommandWrap>) -> std::io::Result<Self> {
+ let mut command_wrap = command.into();
+ command_wrap


let mut command_wrap = command.into(); command_wrap .command_mut() .stdin(std::process::Stdio::piped()) .stdout(std::process::Stdio::piped());

…lcontextprotocol#243 (modelcontextprotocol#245) * allow using a TokioCommandWrap for TokioChildProcess::new closesmodelcontextprotocol#243 TokioCommandWrap implements From<tokio::process::Command> so this is not a breaking change, but also downstream users have more control over flags such as KillOnDrop and CreationFlags see https://docs.rs/process-wrap/latest/process_wrap/#killondrop-and-creationflags

lucasfernog-crabnebula · 2025-06-04T16:17:09Z

Motivation and Context

we need to be able to set KillOnDrop and most importantly CreationFlags for the process spawned - we're now using process-wrap so we need to expose that interface

see https://docs.rs/process-wrap/latest/process_wrap/#killondrop-and-creationflags

How Has This Been Tested?

I'm working on an app that relies on CreationFlags - so i just tested it on Windows :)

Breaking Changes

TokioCommandWrap implements Fromtokio::process::Command so this is not a breaking change, but also downstream users have more control over flags such as KillOnDrop and CreationFlags

Types of changes

Bug fix (non-breaking change which fixes an issue)
New feature (non-breaking change which adds functionality)
Breaking change (fix or feature that would cause existing functionality to change)
Documentation update

Checklist

I have read the MCP Documentation
My code follows the repository's style guidelines
New and existing tests pass locally
I have added appropriate error handling
I have added or updated documentation as needed

Additional context

…lcontextprotocol#243 TokioCommandWrap implements From<tokio::process::Command> so this is not a breaking change, but also downstream users have more control over flags such as KillOnDrop and CreationFlags see https://docs.rs/process-wrap/latest/process_wrap/#killondrop-and-creationflags

jokemanfire · 2025-06-07T02:38:11Z

- .stdin(std::process::Stdio::piped())
+ pub fn new(command: impl Into<TokioCommandWrap>) -> std::io::Result<Self> {
+ let mut command_wrap = command.into();
+ command_wrap


let mut command_wrap = command.into(); command_wrap .command_mut() .stdin(std::process::Stdio::piped()) .stdout(std::process::Stdio::piped());

…lcontextprotocol#243 (modelcontextprotocol#245) * allow using a TokioCommandWrap for TokioChildProcess::new closesmodelcontextprotocol#243 TokioCommandWrap implements From<tokio::process::Command> so this is not a breaking change, but also downstream users have more control over flags such as KillOnDrop and CreationFlags see https://docs.rs/process-wrap/latest/process_wrap/#killondrop-and-creationflags

lucasfernog-crabnebula · 2025-06-04T16:17:09Z

Motivation and Context

we need to be able to set KillOnDrop and most importantly CreationFlags for the process spawned - we're now using process-wrap so we need to expose that interface

see https://docs.rs/process-wrap/latest/process_wrap/#killondrop-and-creationflags

How Has This Been Tested?

I'm working on an app that relies on CreationFlags - so i just tested it on Windows :)

Breaking Changes

TokioCommandWrap implements Fromtokio::process::Command so this is not a breaking change, but also downstream users have more control over flags such as KillOnDrop and CreationFlags

Types of changes

Bug fix (non-breaking change which fixes an issue)
New feature (non-breaking change which adds functionality)
Breaking change (fix or feature that would cause existing functionality to change)
Documentation update

Checklist

I have read the MCP Documentation
My code follows the repository's style guidelines
New and existing tests pass locally
I have added appropriate error handling
I have added or updated documentation as needed

Additional context

…lcontextprotocol#243 TokioCommandWrap implements From<tokio::process::Command> so this is not a breaking change, but also downstream users have more control over flags such as KillOnDrop and CreationFlags see https://docs.rs/process-wrap/latest/process_wrap/#killondrop-and-creationflags

jokemanfire · 2025-06-07T02:38:11Z

- .stdin(std::process::Stdio::piped())
+ pub fn new(command: impl Into<TokioCommandWrap>) -> std::io::Result<Self> {
+ let mut command_wrap = command.into();
+ command_wrap


let mut command_wrap = command.into(); command_wrap .command_mut() .stdin(std::process::Stdio::piped()) .stdout(std::process::Stdio::piped());

…lcontextprotocol#243 (modelcontextprotocol#245) * allow using a TokioCommandWrap for TokioChildProcess::new closesmodelcontextprotocol#243 TokioCommandWrap implements From<tokio::process::Command> so this is not a breaking change, but also downstream users have more control over flags such as KillOnDrop and CreationFlags see https://docs.rs/process-wrap/latest/process_wrap/#killondrop-and-creationflags

lucasfernog-crabnebula · 2025-06-04T16:17:09Z

Motivation and Context

we need to be able to set KillOnDrop and most importantly CreationFlags for the process spawned - we're now using process-wrap so we need to expose that interface

see https://docs.rs/process-wrap/latest/process_wrap/#killondrop-and-creationflags

How Has This Been Tested?

I'm working on an app that relies on CreationFlags - so i just tested it on Windows :)

Breaking Changes

TokioCommandWrap implements Fromtokio::process::Command so this is not a breaking change, but also downstream users have more control over flags such as KillOnDrop and CreationFlags

Types of changes

Bug fix (non-breaking change which fixes an issue)
New feature (non-breaking change which adds functionality)
Breaking change (fix or feature that would cause existing functionality to change)
Documentation update

Checklist

I have read the MCP Documentation
My code follows the repository's style guidelines
New and existing tests pass locally
I have added appropriate error handling
I have added or updated documentation as needed

Additional context

…lcontextprotocol#243 TokioCommandWrap implements From<tokio::process::Command> so this is not a breaking change, but also downstream users have more control over flags such as KillOnDrop and CreationFlags see https://docs.rs/process-wrap/latest/process_wrap/#killondrop-and-creationflags

jokemanfire · 2025-06-07T02:38:11Z

- .stdin(std::process::Stdio::piped())
+ pub fn new(command: impl Into<TokioCommandWrap>) -> std::io::Result<Self> {
+ let mut command_wrap = command.into();
+ command_wrap


let mut command_wrap = command.into(); command_wrap .command_mut() .stdin(std::process::Stdio::piped()) .stdout(std::process::Stdio::piped());

…lcontextprotocol#243 (modelcontextprotocol#245) * allow using a TokioCommandWrap for TokioChildProcess::new closesmodelcontextprotocol#243 TokioCommandWrap implements From<tokio::process::Command> so this is not a breaking change, but also downstream users have more control over flags such as KillOnDrop and CreationFlags see https://docs.rs/process-wrap/latest/process_wrap/#killondrop-and-creationflags

planeyang mentioned this pull request Jun 4, 2025
Stdio doesn't seem to respect cmd flags anymore #243
Closed

jokemanfire reviewed Jun 7, 2025
View reviewed changes

apply suggestion from code review
587903d

jokemanfire approved these changes Jun 7, 2025
View reviewed changes

jokemanfire merged commit db03f63 into modelcontextprotocol:mainJun 7, 2025

lucasfernog-crabnebula deleted the fix/creation-flags branch June 7, 2025 17:55

lucasfernog-crabnebula restored the fix/creation-flags branch June 7, 2025 17:56

github-actionsBot mentioned this pull request Jul 2, 2025
chore: release v0.2.0 #300
Merged

planeyang mentioned this pull request Jun 4, 2025
Stdio doesn't seem to respect cmd flags anymore #243
Closed

jokemanfire reviewed Jun 7, 2025
View reviewed changes

apply suggestion from code review
587903d

jokemanfire approved these changes Jun 7, 2025
View reviewed changes

jokemanfire merged commit db03f63 into modelcontextprotocol:mainJun 7, 2025

lucasfernog-crabnebula deleted the fix/creation-flags branch June 7, 2025 17:55

lucasfernog-crabnebula restored the fix/creation-flags branch June 7, 2025 17:56

github-actionsBot mentioned this pull request Jul 2, 2025
chore: release v0.2.0 #300
Merged

planeyang mentioned this pull request Jun 4, 2025
Stdio doesn't seem to respect cmd flags anymore #243
Closed

jokemanfire reviewed Jun 7, 2025
View reviewed changes

apply suggestion from code review
587903d

jokemanfire approved these changes Jun 7, 2025
View reviewed changes

jokemanfire merged commit db03f63 into modelcontextprotocol:mainJun 7, 2025

lucasfernog-crabnebula deleted the fix/creation-flags branch June 7, 2025 17:55

lucasfernog-crabnebula restored the fix/creation-flags branch June 7, 2025 17:56

github-actionsBot mentioned this pull request Jul 2, 2025
chore: release v0.2.0 #300
Merged

planeyang mentioned this pull request Jun 4, 2025
Stdio doesn't seem to respect cmd flags anymore #243
Closed

jokemanfire reviewed Jun 7, 2025
View reviewed changes

apply suggestion from code review
587903d

jokemanfire approved these changes Jun 7, 2025
View reviewed changes

jokemanfire merged commit db03f63 into modelcontextprotocol:mainJun 7, 2025

lucasfernog-crabnebula deleted the fix/creation-flags branch June 7, 2025 17:55

lucasfernog-crabnebula restored the fix/creation-flags branch June 7, 2025 17:56

github-actionsBot mentioned this pull request Jul 2, 2025
chore: release v0.2.0 #300
Merged

planeyang mentioned this pull request Jun 4, 2025
Stdio doesn't seem to respect cmd flags anymore #243
Closed

jokemanfire reviewed Jun 7, 2025
View reviewed changes

apply suggestion from code review
587903d

jokemanfire approved these changes Jun 7, 2025
View reviewed changes

jokemanfire merged commit db03f63 into modelcontextprotocol:mainJun 7, 2025

lucasfernog-crabnebula deleted the fix/creation-flags branch June 7, 2025 17:55

lucasfernog-crabnebula restored the fix/creation-flags branch June 7, 2025 17:56

github-actionsBot mentioned this pull request Jul 2, 2025
chore: release v0.2.0 #300
Merged

planeyang mentioned this pull request Jun 4, 2025
Stdio doesn't seem to respect cmd flags anymore #243
Closed

jokemanfire reviewed Jun 7, 2025
View reviewed changes

apply suggestion from code review
587903d

jokemanfire approved these changes Jun 7, 2025
View reviewed changes

jokemanfire merged commit db03f63 into modelcontextprotocol:mainJun 7, 2025

lucasfernog-crabnebula deleted the fix/creation-flags branch June 7, 2025 17:55

lucasfernog-crabnebula restored the fix/creation-flags branch June 7, 2025 17:56

github-actionsBot mentioned this pull request Jul 2, 2025
chore: release v0.2.0 #300
Merged

planeyang mentioned this pull request Jun 4, 2025
Stdio doesn't seem to respect cmd flags anymore #243
Closed

jokemanfire reviewed Jun 7, 2025
View reviewed changes

apply suggestion from code review
587903d

jokemanfire approved these changes Jun 7, 2025
View reviewed changes

jokemanfire merged commit db03f63 into modelcontextprotocol:mainJun 7, 2025

lucasfernog-crabnebula deleted the fix/creation-flags branch June 7, 2025 17:55

lucasfernog-crabnebula restored the fix/creation-flags branch June 7, 2025 17:56

github-actionsBot mentioned this pull request Jul 2, 2025
chore: release v0.2.0 #300
Merged

planeyang mentioned this pull request Jun 4, 2025
Stdio doesn't seem to respect cmd flags anymore #243
Closed

jokemanfire reviewed Jun 7, 2025
View reviewed changes

apply suggestion from code review
587903d

jokemanfire approved these changes Jun 7, 2025
View reviewed changes

jokemanfire merged commit db03f63 into modelcontextprotocol:mainJun 7, 2025

lucasfernog-crabnebula deleted the fix/creation-flags branch June 7, 2025 17:55

lucasfernog-crabnebula restored the fix/creation-flags branch June 7, 2025 17:56

github-actionsBot mentioned this pull request Jul 2, 2025
chore: release v0.2.0 #300
Merged

Uh oh!

Conversation

lucasfernog-crabnebula commented Jun 4, 2025

Motivation and Context

How Has This Been Tested?

Breaking Changes

Types of changes

Checklist

Additional context

Uh oh!

jokemanfireJun 7, 2025• edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

lucasfernog-crabnebulaJun 7, 2025

Choose a reason for hiding this comment

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

2 participants

Uh oh!

Conversation

lucasfernog-crabnebula commented Jun 4, 2025

Motivation and Context

How Has This Been Tested?

Breaking Changes

Types of changes

Checklist

Additional context

Uh oh!

jokemanfireJun 7, 2025• edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

lucasfernog-crabnebulaJun 7, 2025

Choose a reason for hiding this comment

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

2 participants

Uh oh!

Conversation

lucasfernog-crabnebula commented Jun 4, 2025

Motivation and Context

How Has This Been Tested?

Breaking Changes

Types of changes

Checklist

Additional context

Uh oh!

jokemanfireJun 7, 2025• edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

lucasfernog-crabnebulaJun 7, 2025

Choose a reason for hiding this comment

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

2 participants

Uh oh!

Conversation

lucasfernog-crabnebula commented Jun 4, 2025

Motivation and Context

How Has This Been Tested?

jokemanfireJun 7, 2025•
edited
Loading

jokemanfireJun 7, 2025•
edited
Loading

jokemanfireJun 7, 2025•
edited
Loading

jokemanfireJun 7, 2025•
edited
Loading

jokemanfireJun 7, 2025•
edited
Loading