Let an Agent Open a Pull Request

Use an MCP sandbox to have an agent open a pull request with a screenshot.

Introduction

30 Second Summary

A useful code change can sit unseen on one laptop until you manually package it for review. That extra handoff turns a quick improvement into another task on your list.

In this project, you will connect an AI agent to a hosted MCP server so it can work inside a remote sandbox. You will guide it from a repository change to a GitHub pull request with a browser screenshot attached.

What You'll Build

You will open GitHub and find a real pull request from your agent, complete with a visible page update and screenshot evidence captured outside your laptop.

By the end of this project, you'll have:

Proof that your agent can clone your code remotely and inspect its files inside a sandbox.
A visible page update that you can inspect through a public screenshot captured by a headless browser.
A review-ready pull request with the screenshot embedded in its description.
Secret Mission: Make a second visual refinement and update the existing pull request with fresh screenshot evidence.

What do I need for this project?

You need a GitHub account that owns a small public repository. You also need an MCP-capable agent with an active subscription.

Before We Start

Before the hands-on work begins, lock in what your agent is about to create and why moving the work into a remote sandbox matters.

Create and Push a Web Page Repo

An agent can only work remotely when it has a repository it can reach. A small repository also keeps the later change easy to review.

In this step, you'll create a public repository on GitHub. You'll add one web page that becomes the agent's starting point.

In this step, get ready to:

Sign in to GitHub through your browser.
Create a public repository under your account.
Commit an index.html page to the default branch.

Sign in to GitHub

GitHub needs to recognize your account before you can create the repository. Only GitHub's sign-in page receives your credentials.

Open the GitHub sign-in page in your browser.
Enter your GitHub account credentials.
Complete any two-factor or device verification that GitHub requests.

You'll arrive at your signed-in GitHub home page. Your account is ready to own the project repository.

Can't complete sign-in?

Use the recovery method configured for your GitHub account. A new browser may also require device verification.

Help me troubleshoot my GitHub sign-in.

Create a public repository

A public repository gives your project a remote home that can be reviewed in the browser. Everything committed to it can be viewed by anyone.

Open the new repository page in your signed-in browser.
Select your personal account from the Owner dropdown.
Choose a short repository name that identifies this demo.
Save your chosen name here: <your-repo>.
Enter <your-repo> in the Repository name field.
Select Public from the Choose visibility menu.
Select Add README to initialize the default branch.
Click Create repository.

Good progress. Your public repository now has a default branch with its first commit.

Repository name unavailable?

Add a short suffix to your chosen repository name.
Update this saved value to match the new name: <your-repo>.
Submit the repository form again.

Help me resolve a GitHub repository creation problem.

Add and verify index.html

The README created a default branch that can accept your page commit. A short message inside index.html gives the agent a visible baseline to change later.

Click the Add file dropdown above the repository file list.
Click Create new file.
Enter index.html in the file name field.
Type a short harmless message of your choice in the file contents text box.
Click Preview to review the page content.

You'll see the message you entered in the preview area. That message becomes the original state shown in the later pull request.

Click Commit changes....
Enter Add initial web page in the Commit message field.
Select the option that commits directly to the current default branch.
Click Commit changes.

The browser editor stores this commit in GitHub's remote repository. Your local machine has no project copy to manage.

Before you inspect the repository, where do you expect the new file to be stored after this commit?

Return to the repository's main page by selecting <your-repo> in the breadcrumb.
Confirm that Public appears beside the repository name.
Confirm that index.html appears in the default branch file list.
Select index.html from the file list.

You'll see your original message inside index.html. This confirms that the page commit is stored in GitHub's remote repository.

Don't see index.html?

Confirm that the repository breadcrumb shows <your-repo>.
Return to the default branch using the branch selector.
Check the file list again for index.html.

Help me find my committed index.html file on GitHub.

✔️ Awesome, I've got everything!

Your public repository is ready. Keep this browser tab available for the later access and pull request checks.

ⓧ I'd like to double check the full code

Your project should match this target state.

A public GitHub repository named <your-repo> exists under your account. Its default branch contains the initial commit.

The default branch also contains index.html with your initial one-page message. The page commit is stored on GitHub.

Your public repository now gives the agent a small remote project to clone. Next, you'll connect the MCP server that performs the work away from your laptop.

Connect the MCP Server

Your public GitHub repository now gives the project a remote home. Your agent still needs a remote workspace before it can work beyond your laptop.

The hosted MCP server gives your agent a remote sandbox. It also exposes Git tools through the same connection.

You will approve that connection with OAuth. You will disable read-only mode so the agent can use write-capable tools later.

In this step, get ready to:

Connect the MCP server to your agent.
Complete OAuth consent with read-only mode disabled.
Confirm remote sandbox and Git tools are available.

Add the MCP endpoint

An MCP client reaches a hosted server through an endpoint. Adding the endpoint tells your agent where to request its remote tools.

Switch back to the agent you used earlier.
Navigate to the area where your agent manages MCP connections.
Choose the option that adds a remote MCP server.
Enter https://mcp.upstash.com/mcp into the server URL field.
Save the connection.

You should see a new MCP connection listed in your agent. The connection is ready to begin authorization.

What does this connection add?

The endpoint connects your agent to tools hosted outside your laptop. Those tools can work inside an isolated remote sandbox.

The same connection also supplies Git capabilities. This prepares the agent to work with a repository after you grant access to it.

Connection not listed?

Check that the endpoint is exactly https://mcp.upstash.com/mcp. Remove any spaces before saving it again.

If your agent rejects the connection, help me troubleshoot the remote MCP setup.

Authorize the connection

OAuth approves the connection without asking you to share account credentials with the agent. The consent page also controls whether the agent receives tools that can change state.

Granting write access can feel broad. Repository access remains a separate grant.

The read-only control is easy to miss on this screen. A quick check here prevents missing write tools later.

Start authorization for the saved connection from your agent’s MCP connection area.
Switch to the browser window opened by your agent.
Complete the account sign-in if the consent flow asks for it.
Turn off the option that limits the connection to read-only access.
Approve the consent request.
Return to your agent.

You should see the connection report a successful authorization.

That permission checkpoint is complete. Your agent can now receive write-capable tools.

Why turn off read-only mode?

A read-only grant disables tools that change state. The agent could inspect information through that grant.

This project later needs write-capable Git actions to create a branch and open a pull request. Disabling read-only mode makes those actions available.

Authorization did not complete?

Start the authorization flow again from the saved MCP connection.
Ask the agent to use the new MCP connection once if no browser window opens.
Allow your browser to open the consent page if it blocks the request.

If the connection still waits for authorization, help me complete the MCP OAuth flow.

Confirm the remote tools

A saved endpoint proves the configuration exists. The available tool list proves your agent can use the remote service.

Before you ask, do you expect the response to contain only local actions or capabilities from the remote sandbox?

Ask the agent to list every tool available from the new MCP connection.
Ask the agent to group the response by purpose if the list is long.
Review the response for remote sandbox tools.
Review the response for Git tools.

You should see at least one remote sandbox capability. You should also see Git capabilities in the response.

The exact tool names can vary between agents. Sandbox tools usually cover remote execution or file operations.

Nice work. Your agent now has a remote workspace plus the Git capabilities needed for the rest of the project.

Remote tools missing?

Confirm the MCP connection remains enabled after authorization.
Repeat the consent flow if the connection still has read-only access.
Ask the agent to refresh its available MCP tools.

If sandbox or Git capabilities still do not appear, help me diagnose my missing MCP tools.

Your MCP connection is ready. Next, you will use Box settings to allow access only to <your-repo>.

Allow Access to Your Repo

Your MCP server remains connected to the agent. Its remote tools are ready for the next stage.

The next goal is to give those tools access to the GitHub repository you created. OAuth authorizes the connection.

Upstash Box uses a separate repository allowlist to control where the agent can work. You will restrict that list to <your-repo>.

In this step, get ready to:

Review the current repository scope in Box settings.
Allow only <your-repo> for remote access.
Verify that your repository is the sole entry in the allowed-repository list.

Review the repository boundary

The repository allowlist defines the boundary around the agent's remote sandbox. Every repository shown there is available to the remote tools.

Return to the MCP server console from earlier.
Select Box settings in the console.
Check the allowed-repository list for repositories that already have access.

The current list shows the exact repository scope available to your agent.

Allow only your project repository

Granting write access can feel broad. A one-repository selection keeps this project contained.

Use the repository selector inside Box settings to select <your-repo>.
Remove every other repository from the selection.
Save the repository selection with the confirmation control shown by the console.

The selected scope should update to one repository.

That is the sensitive part handled. Your agent can reach the practice repository while your other repositories remain outside this workflow.

Can't find your repository?

Confirm that the signed-in GitHub account owns <your-repo>. Refresh Box settings after confirming that the repository is public.

Help me troubleshoot why my repository is missing from Box settings.

Verify the allowed list

The saved list must survive a page refresh. This check proves that the console stored the access boundary.

Before you refresh the settings, which repository do you expect to remain on the allowed list?

Refresh the Box settings page.

You should see only <your-repo> on the allowed-repository list. This confirms that the agent has remote access to your project repository only.

Your repository boundary is set. Next, you will ask the agent to clone <your-repo> in the remote sandbox and prove that the work happens away from your laptop.

Verify the Remote Sandbox

You limited your agent to one GitHub repository in the previous step. The MCP connection now has a narrow path into that repository.

The key proof is a clone plus a file listing inside the remote Box sandbox. That evidence separates remote agent work from activity on your laptop.

In this step, get ready to:

Clone the only allowed repository into the remote Box sandbox.
List the files from the cloned repository.
Verify that the tool output came from the Box sandbox.

Clone the allowed repository

A clone gives the remote sandbox its own working copy of your GitHub repository. The agent can use that copy without touching your laptop's file system.

Switch back to the agent conversation from earlier.
Send a message asking the agent to clone the only repository allowed in Box settings into the remote Box sandbox.

You should see the agent use its remote tools to clone the repository. The agent should report that the clone completed inside the Box sandbox.

Clone did not complete?

Return to the Box settings from earlier.
Confirm that your repository remains the only allowed repository.
Return to the MCP connection settings from earlier.
Confirm that read-only mode remains disabled.

Ask for help with the access path by selecting help me diagnose this repository clone problem.

List the sandbox files

A file listing gives you a small result that is easy to compare with the repository on GitHub. Your initial page provides a clear marker through index.html.

Before you ask for the listing, do you expect the agent to return files from the remote clone or files from your laptop?

Send a message asking the agent to run a file-listing command from inside the remote clone.

You should see index.html among the returned files. This matches the initial page on the repository's default branch.

What Does the Listing Prove?

The tool result shows that the repository exists inside the agent's sandbox. Seeing index.html confirms that the remote clone contains the page you pushed earlier.

Missing index.html?

Ask the agent to identify the directory used for the file listing.
Ask the agent to repeat the listing from inside the cloned repository.
Compare the repository name in the tool result with the repository allowed in Box settings.

Ask for help tracing the clone by selecting help me find why the remote clone does not show index.html.

Confirm the execution location

Each agent tool call has an execution context. The context attached to the listing tells you where the shell actually ran.

Before the final check, what detail in the tool result would prove that the listing ran away from your laptop?

Ask the agent to identify the environment that ran the file-listing command using evidence from its tool result.
Read the agent's explanation of the tool result.
Confirm that the explanation identifies the remote Box sandbox as the execution location.

You should see the agent attribute the file listing to its remote Box sandbox. That result confirms the repository was cloned remotely.

You have now proved that the agent can work from a remote copy of your repository while your laptop stays out of the execution path.

Your remote workspace is ready for real work. Next, the agent can change the page and capture the result in a remote browser.

Change and Screenshot the Page

Your agent has already cloned your GitHub repository into the remote sandbox. It also proved that it can inspect the repository without using your laptop.

The connected MCP server provides a remote headless browser that can render the page inside that environment. Your next goal is to create visual evidence of a remote change.

A changed file can be difficult to judge from an agent response alone. A screenshot lets you inspect the result before the change reaches a pull request.

In this step, get ready to:

Request one visible change to index.html inside the remote sandbox clone.
Capture the changed page with the remote headless browser.
Open the returned image URL to confirm the requested change.

Request a visible page change

The sandbox clone is separate from the default branch of <your-repo>. Keeping the edit inside that clone gives you a safe result to review before anything is merged.

Switch back to the agent chat from earlier.
Pick one obvious page-level change such as different heading text or a different background colour.
Ask the agent in your own words to make that change in index.html inside the remote sandbox clone of <your-repo>.
Tell the agent to leave the change inside the sandbox clone for now.

You should see a response confirming that index.html was updated in the remote clone. Your GitHub default branch remains unchanged.

That is the first payoff: your agent now has an unmerged visual change inside the sandbox clone.

Agent changed the wrong copy?

The agent may have edited another clone if the repository location was unclear.

Restate that the target is the existing remote sandbox clone of <your-repo>.
Restate that the file to change is index.html.

Help me confirm that my agent changed the correct index.html file in the remote sandbox clone.

Capture the changed page remotely

The remote headless browser renders the modified page inside the sandbox. Its screenshot proves that the remote environment can display the agent's change.

Ask the agent in your own words to load the changed page with the remote headless browser.
Ask the agent to capture a screenshot after the changed page renders.
Ask the agent to return the image URL from that screenshot.

You should receive an image URL in the agent's response. That link points to the screenshot captured by the remote browser.

Record the returned image URL here: your returned image URL.

No image URL returned?

The agent may have described the page without capturing an image.

Ask the agent to use the remote headless browser from the connected MCP server.
Request a fresh screenshot of the rendered page.
Request the returned image URL explicitly.

Help me get an image URL from the remote page screenshot.

Verify the screenshot result

Opening the returned image turns the agent's text response into something you can inspect. The visible change should match the request you made.

Before you open the image, which visible change do you expect to see?

Open your returned image URL in the browser from earlier.
Compare the screenshot with the visible change you requested.

You should see the exact visible change you requested on the rendered page. This confirms that the remote browser loaded the modified index.html from the sandbox clone.

Screenshot missing the change?

The agent may have captured the initial page or loaded a different copy of the file.

Ask the agent to reopen the changed index.html from the existing remote sandbox clone.
Request a fresh screenshot after the changed page renders.
Open the new image URL in your browser.

Help me debug why the remote screenshot does not show my requested page change.

That is a strong handoff: the remote page change now has visual proof. Next, your agent will turn it into a pull request you can review on GitHub.

Open the Pull Request

Your remote browser already proves that the edited page looks right. The change still lives only inside the agent's remote sandbox.

A pull request turns that sandbox work into a reviewable GitHub artifact.

Your agent will record the index.html change on a branch. It will open the pull request with the screenshot embedded.

In this step, get ready to:

Commit the visible index.html change on an agent-created branch.
Open a pull request to the default branch with the remote-browser screenshot embedded.
Review the pull request on GitHub.

Commit the remote change

A Git commit records the exact index.html change that produced your screenshot. A separate branch keeps that commit ready for review.

Switch back to the agent conversation connected to the MCP server from earlier.
Ask the agent to place the existing index.html change on a new pull-request branch as a commit.

You should see the agent report that it created a commit on a new branch. That page change is now captured as a reviewable unit of work.

Record the branch name here: your agent-created branch name.

Agent cannot commit the change?

The agent may be looking in the wrong folder if it cannot find the existing page change.

Ask the agent to inspect the remote clone of <your-repo> for the existing index.html change.
Ask the agent to retry after it confirms that the change is present.

help me find and commit the existing change in my agent's remote sandbox.

Open the pull request

The pull request keeps the default branch unchanged until you decide to merge it. The embedded screenshot lets a reviewer compare the code change with its rendered result.

Ask the agent to open a pull request from your agent-created branch name to the default branch of <your-repo> with the earlier remote-browser screenshot embedded in the description.

The agent should return a GitHub URL for the new pull request.

Record the returned URL here: your pull request URL.

That returned URL is the durable handoff from the agent's sandbox to your review.

Pull request creation failed?

A write failure can happen when read-only mode is enabled or the allowed repository has changed.

Return to the MCP server console's Box settings from earlier.
Confirm <your-repo> remains the only allowed repository.
Return to the agent's MCP server connection from earlier.
Confirm read-only mode remains disabled.

help me diagnose why my connected MCP agent cannot open a pull request.

Review the pull request

The pull request is where you verify the agent's work before it reaches the default branch. Its file diff proves the code change.

Before you open the pull request, what two pieces of evidence do you expect to find?

Open your pull request URL in your signed-in browser from earlier.

You should see an open pull request from your agent-created branch name to the repository's default branch.

Review the changed-file view for index.html.

You should see the visible page change that you previously confirmed in the remote-browser screenshot.

Return to the pull request description.
Open the embedded screenshot.

You should see the same visible page change in the embedded image. This confirms that the code review includes visual evidence from the remote browser.

Leave the pull request open after your review.

That is the handoff complete. Your agent produced a reviewable change with visual evidence.

Secret mission

Audit the Agent's Pull Request

Challenge your agent to prove that its pull request contains only the intended page change. Then make it verify that the embedded screenshot still matches the current branch without altering the repository.

Clean Up Your Resources

The hosted MCP server adds no separate charge beyond the agent tokens already in use. Choose the cleanup level that matches whether you plan to continue this project.

Resources you used:

Public GitHub repository <your-repo> with its default branch plus its agent-created pull-request branch.
Open pull request in <your-repo> with the remote-browser screenshot embedded in its description.
Allowed repository grant for <your-repo> in the MCP server console's Box settings.
OAuth authorization connecting the MCP server to your agent.

Clean Up Both Permissions

Repository access plus OAuth authorization are separate grants. Removing <your-repo> from Box settings ends access to that repository.

Revoking OAuth ends the broader MCP server connection. These controls let you remove repository write access without deleting your GitHub work.

Keep everything running

No action needed. Choose this if you are still reviewing the pull request or asking the agent to continue working.

Keep the pull request open while you review the agent-created change.
Keep <your-repo> on GitHub to preserve the page plus its pull request history.
Leave <your-repo> in Box settings only while you still want the agent to access it.
Leave the OAuth authorization active only while you still use the MCP server with your agent.

Pause - I'll come back to this later

Remove repository write access while preserving your GitHub work. Choose this if you expect to return later.

Return to the pull request page from earlier.
Merge or close the pull request on GitHub.
Return to the MCP server console from earlier.
Open Box settings.
Remove <your-repo> from the allowed repositories list.
Confirm that <your-repo> is no longer listed as allowed.
Keep the OAuth authorization active so you can reconnect repository access later.

Delete - I don't want to use this again

Permanent repository deletion also removes its pull request history. The Pause option preserves that work without active repository access.

Return to the pull request page from earlier.
Close the open pull request on GitHub.
Confirm that the pull request now shows a closed status.

The allowed repository grant controls which repository the agent can reach through the remote sandbox.

Return to the MCP server console from earlier.
Open Box settings.
Remove <your-repo> from the allowed repositories list.
Confirm that the allowed list no longer includes <your-repo>.

The GitHub repository holds the page plus the agent-created branch. Deleting it removes the project artifact from your account.

Return to the <your-repo> repository on GitHub.
Open the repository settings.
Use the repository deletion control to permanently delete <your-repo>.
Confirm that the repository page is no longer available.

The OAuth authorization is the final connection between the MCP server plus your agent. Revoking it removes that connection.

Open your GitHub account settings.
Locate the OAuth authorization you approved for the MCP server.
Revoke the OAuth authorization.
Ask the agent to list its available MCP tools.

The agent should no longer be able to use the MCP server's sandbox, git, or headless-browser tools.

Nice Work!

You did it! Your agent opened a reviewable pull request in a GitHub repository you own.

You've learned how to:

Connected your agent to an MCP server through OAuth. Box settings limited its access to the repository you selected.
Used a remote sandbox to clone your repository. The agent committed the visible index.html change on a pull-request branch.
Captured the changed page with a headless browser. The agent embedded the screenshot in the pull request description as visual evidence.
Completed an optional Secret Mission to push your agent workflow skills further.

Ready to quiz yourself?