URL redirect changes made by an agent, shown as diffs

What the agent can do

• Filesread_file, edit_file, grep, glob and list_dir work on route lists and configuration files in the chat's working folder, and edit_file shows a diff first.
• Shellruns your config test, reload and request commands and judges success by the real exit code. Dangerous commands are blocked.
• Webweb_search and http_get read official documentation and fetch one page of your own service, so you can compare it with what you expected.
• Screenshots and imagesocr reads text from a saved screenshot, such as an error page from a browser, and gen_image saves real image files into the working folder.
• Orchestrationtask runs parallel sub-agents, run_on_model sends a hard step to a bigger model, and skill keeps reusable playbooks, including a version-control skill for branches and commits of your route files.
• Approval modesAuto-run acts at once, Ask first pauses before changes, and Plan only writes a plan and runs nothing.
• Cronruns a prompt on a schedule, so a recurring check of your own address, for example a request whose status code you then read, can start without you opening the chat.
• Modelsconnect a cloud AI provider through a standard API endpoint, a model running locally on your PC, or the built-in model, which is ready to use without your own endpoint.

Four tasks, step by step

Replace a 302 with a 301 redirect

A page that moved for good but still answers with a temporary code keeps telling search engines and visitors that the old address is current. list_dir and grep find the rule file that mentions the old path, and read_file shows the line that sends code 302. edit_file changes that code to 301 and shows the diff. In Ask first mode the agent pauses here. Nothing reloads yet. Shell then runs your config test command, reloads, and sends a request to the old address, and the card shows the status code and the Location header. Compare them with the values you wrote down before the change, and accept the diff only when both match. Put the code you expect into your plan before you start, so that the comparison is a check against a written value and not against memory.

Break an endless redirect chain

An infinite redirect loop behind a reverse proxy usually means that two layers each force https, so the browser never reaches the page. grep searches for the word redirect in the proxy file and in the settings file of the application, and read_file opens both. Two rules. edit_file removes the duplicate from one of them and shows a diff. Shell runs your config test command, and a request command follows the redirects you ask it to follow, so the exit code and the number of hops appear in the card. Review the diff, keep a backup of the old file, and start with Plan only if the server is live. After the fix, request the address once more and count the hops: one is right, two or more means another rule still redirects.

Join www and the bare domain

Two addresses that serve the same site split your visitors, so pick one and send the other to it with a single url redirect. Write the rule for your own domain, such as www.example.com to example.com, into a plan file first. read_file opens the current rules, edit_file adds the permanent redirect with a diff, and Shell runs your config test command and a request command against both names. Chains slow visitors down and can loop. The second request must therefore show one hop only. Review the diff in Ask first mode, and confirm that the rule sends visitors to the same content they asked for. A redirect that leads somewhere unrelated is a mistake, and it is not what the rule is for.

Edit a proxy on a remote server

A reverse proxy on a remote VPS that you administer can be reached through the SSH environment, where Shell commands run on the server while the file tools work in the chat's working folder. Choose that environment, run your config test command and your reload command through Shell, and read the real exit code in each card. Auto-run would act at once. Ask first is the better choice for a live server, because every change waits for your OK. Afterwards request the public address and compare the status code with the one you noted before. Keep a backup of the old configuration on the server and a way to roll back. Use this only on servers that you own or administer.