Agentic Copilot Repeatedly Kills Long-Running Server Process by running new commands in the same terminal

[beejones]

Select Topic Area

Bug

Copilot Feature Area

VS Code

Body

🐞 Bug Report: Agentic Copilot Repeatedly Kills Long-Running Server Process by running new commands in the same terminal

Summary

When using GitHub Copilot in agent mode, Claude sonnet 4, I observed that it consistently executes new commands in the same terminal where a long-running server process was started. This behavior causes the server to be terminated prematurely.

Steps to Reproduce

1. Start a long-running server process using Copilot in agent mode using Claude sonnet 4 as model.
2. Allow Copilot to execute a subsequent command (e.g., curl).
3. Observe that the new command is run in the same terminal, killing the server, even after repeated request not to do so.

Expected Behavior

Copilot should not run any new commands in the same terminal where the server was started, especially after being explicitly instructed not to do so.

Actual Behavior

Despite multiple feedbacks and explicit instructions, Copilot continues to reuse the same terminal. This results in the server being killed repeatedly.
Even when I create a new terminal to run the command, copilot will still select the wrong terminal and runs the command in the server terminal.
A lot of work is lost because we need to restart to process.

Evidence

Copilot itself acknowledged the issue with the following comment:

You're absolutely right, and I apologize for killing the server again. That's a clear bug in my logic - I should never run commands that kill the server when you've specifically asked me not to do that. Let me restart the server properly and then fix the real-time UI update issue and the timeline styling problem.

However, after restarting the server, Copilot ran a curl command in the same terminal again, killing the server once more.

Additional Context

I have included a .copilot/instructions.md file with the explicit instruction:

Do not run commands in the same terminal where the server was started.

Yet this instruction is not being respected.

Suggested Fix

Ensure that Copilot:

• Tracks terminal context and isolates long-running processes.
• Honors .copilot/instructions.md directives reliably.
• Implements safeguards to prevent command execution that disrupts active processes.

---

Let me know if you need logs, config files, or a reproducible environment to investigate further.

[github-actions[bot]]

💬 Your Product Feedback Has Been Submitted 🎉

Thank you for taking the time to share your insights with us! Your feedback is invaluable as we build a better GitHub experience for all our users.

Here's what you can expect moving forward ⏩

• Your input will be carefully reviewed and cataloged by members of our product teams. 
  • Due to the high volume of submissions, we may not always be able to provide individual responses.
  • Rest assured, your feedback will help chart our course for product improvements.
• Other users may engage with your post, sharing their own perspectives or experiences. 
• GitHub staff may reach out for further clarification or insight. 
  • We may 'Answer' your discussion if there is a current solution, workaround, or roadmap/changelog post related to the feedback.

Where to look to see what's shipping 👀

• Read the Changelog for real-time updates on the latest GitHub features, enhancements, and calls for feedback.
• Explore our Product Roadmap, which details upcoming major releases and initiatives.

What you can do in the meantime 💻

• Upvote and comment on other user feedback Discussions that resonate with you.
• Add more information at any point! Useful details include: use cases, relevant labels, desired outcomes, and any accompanying screenshots.

As a member of the GitHub community, your participation is essential. While we can't promise that every suggestion will be implemented, we want to emphasize that your feedback is instrumental in guiding our decisions and priorities.

Thank you once again for your contribution to making GitHub even better! We're grateful for your ongoing support and collaboration in shaping the future of our platform. ⭐

[beejones]

I tried opening a new terminal before running a new command but copilot was stubborn and went back to the server terminal, killed the server process in order to run the command

[Artimunor]

before it started to kill servers, it was frantically spawning new terminals on every prompt. this looks like a very buggy patch to a previous bug and makes me wonder if vscode copilot gets the love it deserves. it seems experimental at best and they are running behind small startups, copy their features in a buggy way... does github not see agentic coding is the future and they have only one chance to get this right? bugs like this should not exist in production and be rolled out to everyone in stable versions.

[CyrusZei]

Yup, this is an issue. There should be an option to give the co-pilot a "terminal context"

I noticed the "Agent awareness of user-created terminals," but that does not work.

Consider adding a setting when you create a new terminal to add, like a checkbox to let Co-Pilot have access to that as context.

[joshfromperth]

Yeah, this is a huge nuisance for me. I'm unable to get it to understand or obey instruction that it's killing the very terminal running it's trying to inspect the running service of. Big leap forward with terminal interactions, but this is a huge blocker.

[RoySalisbury]

This is driving me crazy. I have tried every promot I can think of. And when it runs as a "task", copilot never sees the output and seems to think everyhting worked just fine. I've had builds that clearly showed erros in the output window, but copilot was "everything is good". But when runin the terminal, it see the output fine. But then its not in the background so it cant start the process (web site) and then run a curl command. ... This is a huge issue..

[CalfCrusher]

Same behaviour. What the heck is happening ? It's since 1 entire week. I will unsubscribe to this garbage

[jhandel]

I am glad I am not crazy and other folks are experience this too.. but yes, it would be grand to fix this..

[darkedges]

Please fix. It should be simple enough to code and would save so many going down a rabbit hole moments because it starts and tests in the same window.

It gets doublely frustrating when you try and seperate API from UI, as it will only start the UI server for example despite it depending on the API server in the odd moment when it does perform a test in a seperate console.

[duongtx90]

I’ve used a workaround to bypass this issue, and I’m sharing it here in case you want to try it.
First, create two scripts: one to start the server and one to stop it.

Stop script

# Kill any existing dev server first
if [ -f .dev-server.pid ]; then
    OLD_PID=$(cat .dev-server.pid)
    if ps -p $OLD_PID > /dev/null 2>&1; then
        echo "Stopping existing dev server (PID: $OLD_PID)..."
        kill $OLD_PID
        sleep 2
    fi
    rm -f .dev-server.pid
fi

# Start new dev server
echo "Starting dev server..."
npm run dev > server.log 2>&1 &
NEW_PID=$!

# Save PID to file
echo $NEW_PID > .dev-server.pid
echo "Dev server started with PID: $NEW_PID"
echo "Log file: server.log"
echo "To stop: ./kill-server-dev.sh"

Start Script

# Check if PID file exists
if [ ! -f .dev-server.pid ]; then
    echo "Error: PID file not found (.dev-server.pid)"
    echo "Server may not be running or was started manually."
    exit 1
fi

# Read PID from file
PID=$(cat .dev-server.pid)

# Check if process is running
if ! ps -p $PID > /dev/null 2>&1; then
    echo "Warning: Process $PID is not running."
    rm -f .dev-server.pid
    exit 1
fi

# Verify it's actually our dev server
if ps -p $PID -o command= | grep -q "npm run dev"; then
    echo "Stopping dev server (PID: $PID)..."
    kill $PID
    
    # Wait for process to terminate
    for i in {1..10}; do
        if ! ps -p $PID > /dev/null 2>&1; then
            echo "Dev server stopped successfully."
            rm -f .dev-server.pid
            exit 0
        fi
        sleep 1
    done
    
    # Force kill if still running
    if ps -p $PID > /dev/null 2>&1; then
        echo "Process not responding, force killing..."
        kill -9 $PID
        sleep 1
    fi
    
    rm -f .dev-server.pid
    echo "Dev server stopped."
else
    echo "Error: PID $PID is not a dev server process."
    echo "Removing stale PID file."
    rm -f .dev-server.pid
    exit 1
fi

Then add instruction to copilot instructions to guide Agent how to start/stop & check server log

## Development Workflows
### Running the Dev Server
**IMPORTANT**: Use the custom scripts to run/kill the dev server in the background during developemtn, use server.log to check logs.
./run-dev.sh             # Background dev server (logs to server.log)
./kill-server-dev.sh     # Kill background server

[cloudify]

My solution to this is to instruct the agent to use tmux then running commands

[joshfromperth]

Hey guys, I've actually noticed a lot less drama with this since the latest Github Copilot update because it runs things in hidden terminals and it seems to track things better in them - I think it spawns a new terminal more sensibly now. HOWEVER, I have had more success with running my apps with pm2 for example which then my agent knows to restart that service or start it up, but it all runs in the background so it can't as easily kill the terminal it started the process in! It's been working much better than running straight from the terminal and node.

…

On Tue, 17 Feb 2026 at 17:13, Federico Feroldi ***@***.***> wrote: My solution to this is to instruct the agent to use tmux then running commands — Reply to this email directly, view it on GitHub <#170008 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AA5JSXUUIZWTKYC3DTPL3DL4MLLUDAVCNFSM6AAAAACEBPYAA6VHI2DSMVQWIX3LMV43URDJONRXK43TNFXW4Q3PNVWWK3TUHMYTKOBTGI4TOMI> . You are receiving this because you commented.Message ID: ***@***.***>

-- Kind regards, Joshua A