Viktoria

Posted on Sep 10

Why the agent needs access to the environment, not a human’s retelling of it

#ai #webdev #programming #javascript

A retold log is a filtered log. The agent should query the database, read the broker, hit the endpoint itself — and record what it saw.

There is a moment in almost every debugging session with an AI agent where the developer stops being a developer and becomes a clipboard. The agent asks for the error. The developer runs the command, scrolls, selects the part that looks relevant, pastes it. The agent asks for the row in the database. The developer opens a SQL client, runs a query, pastes the result. The agent asks what the endpoint returned. Another terminal, another paste.

Each paste is a decision about what matters, made by the person who does not yet know what matters.

I am the product manager at Explyt, where we build an AI agent for JetBrains IDEs. I have written before about a session in our own agent where the developer pasted SQL results, Kafka and Spring logs, HTTP responses and Kubernetes messages by hand while the agent's terminal use was limited to git (One symptom, ten problems). That session sent me looking for how common the pattern is outside our own logs. The issue trackers are full of it, and Anthropic's engineering posts describe the fix while the same company's prompt examples still say "[paste error]".

TL;DR

Public issues on Claude Code and Copilot, plus Reddit threads about Cursor and Claude Code, document the same loop: the agent cannot see the terminal, the database or the CI logs, so the human copies output into the chat, and the agent reasons about the copy.
The copy passes through several filters: what the human chose to run, what they chose to select, what the tooling truncated without saying so, and what the agent's own compaction later summarized away. Each filter removes the kind of detail that debugging turns on.
When the agent does have access, it often leaves it unused. Issues show agents guessing column names with SSH access available, confirming a production config without checking, and asking the human to run a query the agent's own MCP server could run.
Anthropic's engineering guidance says agents need "ground truth" from the environment at each step. The instruments to get it exist as MCP servers for databases, Kafka and Kubernetes, most with read-only modes.
Direct access is half of the fix. The other half is a record of what the agent queried, what came back, and which conclusion rests on which observation.

The relay loop, in the words of the people stuck in it

anthropics/claude-code #69360 (June 2026): "Claude Code (VS Code extension) cannot read the existing terminal output. When a user runs a command that produces errors, they must manually copy-paste the output into the chat. This adds friction to the debugging workflow and breaks the natural "run → see error → ask Claude" loop."

anthropics/claude-code #13865 (December 2025) spells out the steps and names the consequence: "Currently, if I want to debug a runtime issue, I have to: 1. Manually ask Claude to add print/log statements. 2. Manually run the app/script. 3. Copy/paste the terminal output back into Claude Code. 4. Ask Claude to analyze it. 5. Ask Claude to remove the logs afterwards. This manual "human-in-the-loop" data transfer is slow and error-prone, often leading to "shotgun debugging" where the model guesses the solution without concrete runtime evidence."

The Copilot side has the same report from the other direction. In microsoft/vscode-copilot-release #10778 (May 2025): "The agent fails to see the output from the terminal so it starts to run another command in a different way repeatedly failing to see the output. If I select the terminal output and select add to chat, it can see the output." An agent that cannot see the result of its own command reruns it and still sees nothing; in that thread the paste was the only channel that worked.

Reddit adds the texture. A Cursor user in r/ClaudeAI (December 2025): "Cursor also can't directly read and make use of the error logs in the PowerShell console. It feels broken for me to manually copy paste the logs to the Cursor agent." Another in r/cursor (June 2026), after a tooling change: "Only option is copy the command and re-run it yourself, which kind of defeats the whole point of having an agent run things!"

These are personal accounts with low vote counts, and I cite them as such. What they share with the GitHub issues is the shape: for everything outside the repository, the human carries the data.

Four filters between the environment and the agent

A retold log is filtered whether or not anyone intends it.

1. What to run

The first filter is the choice of what to run. The developer decides which command, which query, which endpoint. If the hypothesis in their head is wrong, the evidence they collect is evidence for or against the wrong hypothesis, and the query that would have tested the right one never runs.

2. What to select

The second is the choice of what to select. Nobody pastes a 4,000-line log. They scroll to the stack trace or the last twenty lines and paste that. The warning three seconds earlier and the second exception in a different thread stay in the terminal.

3. Truncation by tooling

The third is the one nobody chooses: truncation by tooling. A r/ClaudeCode thread (April 2026) tested a popular token-saving wrapper. On a package listing: "The remaining 314 packages are invisible. There is no truncation indicator. The output looks complete." In a separate example on log levels, the same author describes the downstream effect: "An AI agent doing incident triage reads the logs, sees one error (a transient retry), and concludes it's a minor blip. It applies a small fix and closes the investigation." Truncation is also the default in the agent itself: "For Claude Code, we restrict tool responses to 25,000 tokens by default", from Anthropic's Writing effective tools for AI agents.

4. Compaction

The fourth looks like memory. Anthropic's context engineering post describes compaction as "summarizing its contents, and reinitiating a new context window with the summary", where "the model preserves architectural decisions, unresolved bugs, and implementation details while discarding redundant tool outputs or messages." The word "redundant" is doing a lot of work there. In a debugging session, the tool output that looked redundant at the time of compaction is often the one you need two hours later.

Stack the four and the agent is reasoning about a document written by a human with a hypothesis, cut to fit a chat box, truncated by a wrapper, and then summarized. It is a wonder it gets anything right.

Four filters between the environment and the agent. Each one removes the kind of detail debugging turns on.

When the agent has access and still asks you

Direct access turns out to be necessary and, on its own, insufficient, because agents with access often leave it unused.

anthropics/claude-code #43387 (April 2026) is the sharpest example I found. The agent "Wrote 1,700 lines of PHP with 28 database actions using completely guessed column names — never ran SHOW COLUMNS or any test query against the real database." The reporter adds: "Claude has SSH access to the server and could run SHOW COLUMNS, curl endpoints, or test queries — but never does before saying "done"." Thirty of forty-six queries referenced columns that did not exist while the SSH session sat unused.

anthropics/claude-code #60107 (May 2026, a report the user had the agent itself write up) moves the same failure to production: "Claude Code confirmed a Postgres dialect option (statement_timeout) as valid for a Heroku-hosted production app when I explicitly asked "are you sure this is a valid option?". The agent answered "yes" without verifying against the actual prod environment. The change passed all local tests (local Postgres in Docker has no pgbouncer), shipped to production, and crashed every dyno at boot." Local and production gave different answers to the same question, and the agent queried neither.

anthropics/claude-code #86718 (August 2026) is the near-miss: the agent "without verifying, concluded that a database record … had been overwritten/corrupted … and stated this as fact", and "had already suggested deleting the affected database record before I stopped it." The agent guessed that data was damaged and proposed deleting it before anyone had checked.

And from the MCP side, a r/cursor user (July 2025) with a Postgres MCP server connected: "Tried 4 different models to try to get it to query my dev database, all attempts fail with the model just asking me to run the query myself." A r/ClaudeCode user (July 2026) on CI: "it tried a bunch of local builds before then asking me to paste in the logs from the failed CI deployment. It has access to the CI logs, and has used them in the past."

So the instruments have to be there, and the agent has to be held to using them. The second part is a harness and prompting problem, and I come back to it below.

What Anthropic says the agent should do

Anthropic, Building effective agents: "During execution, it's crucial for the agents to gain "ground truth" from the environment at each step (such as tool call results or code execution) to assess its progress."

Anthropic, Claude Code best practices: "Claude stops when the work looks done. Without a check it can run, "looks done" is the only signal available, and you become the verification loop: every mistake waits for you to notice it." The same page defines the check as "anything that returns a signal Claude can read in the conversation: a test suite, a build exit code, a linter, a script that diffs output against a fixture, or a browser screenshot compared against a design".

The same page also, in its prompt-example table, recommends writing "[paste error]" to the agent. I mention it because it shows how deep the relay habit runs: even the document that tells you to make the agent its own verification loop assumes the human will hand it the error.

The context engineering post gives the alternative, and the alternative is many small retrievals made by the agent itself: "Letting agents navigate and retrieve data autonomously also enables progressive disclosure", and "The model can write targeted queries, store results, and leverage Bash commands like head and tail to analyze large volumes of data without ever loading the full data objects into context."

The research on long contexts points the same way. Lost in the Middle (Liu et al., 2023) found that "performance can degrade significantly when changing the position of relevant information", and Chroma's Context Rot report (2025), across 18 models, concludes that "models do not use their context uniformly; instead, their performance grows increasingly unreliable as input length grows." A bigger paste makes the second problem worse while leaving the first four filters in place.

The instruments exist

"Query the database, read the broker, hit the endpoint" sounds like a wish list. As of September 2026 it is a list of MCP servers, most with a read-only switch. Star counts and dates are from the GitHub API on 2026-09-08.

Databases

For databases: crystaldba/postgres-mcp (3.3k stars) has a "Restricted Mode" that "Limits operations to read-only transactions and imposes constraints on resource utilization" and is described as "suitable for production environments". bytebase/dbhub (3.5k stars, release 2026-09-02) covers Postgres, MySQL, SQL Server, MariaDB and SQLite with "Read-only mode, row limiting, and query timeout to prevent runaway operations". Google's MCP Toolbox for Databases (16k stars) ships "Prebuilt generic tools for instant data exploration (e.g., list_tables, execute_sql)". The original reference Postgres server from the Model Context Protocol project is archived; the current reference set is filesystem, git, fetch, memory and a few others.

Kafka

For Kafka: confluentinc/mcp-confluent (v1.5.0, July 2026) exposes list-topics, consume-messages and list-consumer-groups, and also produce-message, create-topics and delete-topics. It has no read-only flag, but its --allow-tools and --block-tools options let you start it with the write tools removed, which is how I would run it for debugging.

Kubernetes

For Kubernetes: containers/kubernetes-mcp-server (2.1k stars, actively maintained) has --read-only, which "will not allow any write operations (create, update, delete)", plus --disable-destructive, and a pods_log tool that does the obvious thing.

HTTP

For HTTP: the reference fetch server converts pages to markdown, so it fetches web pages and does no API work. For "hit the endpoint itself" you want the agent's terminal with curl, or a purpose-built server.

Each of these servers exposes access the developer already has, behind a permission model.

Connecting an MCP server in Explyt (STDIO transport). The docs example is the sequential-thinking server; a database or Kafka server is configured the same way, with its read-only flags in the arguments.

The other half: record what it saw

I disagree with the simplest version of my own thesis. Give the agent a terminal, a database and a broker, and you have replaced a filtered log with an unfiltered stream that nobody reads. The developer stops being the clipboard and becomes the person who has to trust a conclusion with no visible chain of evidence.

The fix is the one that works for human engineers: a record. Which query ran, against which environment, what came back, and which conclusion rests on which result. Anthropic's tooling post recommends the reviewer's version of this: "Review the raw transcripts (including tool calls and tool responses) to catch any behavior not explicitly described in the agent's CoT." The agent's version is to keep that record itself, in the open, as it works.

Every claim about the environment carries the observation it came from: the query, the environment and the timestamp next to the value.

In practice I now hold any agent I use for debugging to a short set of rules.

Every claim about the environment carries the observation it came from: the query, the environment and the timestamp next to the value, so "the row has status = PENDING" arrives with "query at 14:02 against staging".
The environment is named every time, because #60107 above is what happens when local and production are treated as one.
And the record survives compaction: if the agent summarizes its own context, the observations stay in a file that the summary links to.

The problem sits in the harness as much as in the model. #43387 and the two MCP stories above show models with access declining to use it. A rule in the repository's agent instructions that says "before stating anything about database, broker or runtime state, query it and quote the result" is blunt. In my own sessions it removed most of the guessed claims.

Where Explyt stands

Explyt is our agent for JetBrains IDEs, and I want to state what its documentation does and does not cover on this topic.

The tools documentation frames the goal in the same terms as this article: tools "give the agent facts about your project and let it perform actions without you manually copying long logs and search results into the chat."

Once connected, each MCP server appears in the Tools menu as its own group next to the built-in IDE tools. Screenshot from the Explyt documentation.

Two of those sources come from the IDE itself, not from anything a database or a broker exposes, and I start with them because they are the ones a paste cannot replace.

Run configurations: the agent runs a configured test, build or application through the IDE and "returns the result to the agent: console output, test results, compilation errors." That closes the "copy the terminal output back" loop from #13865 for anything the IDE knows how to run. The docs are explicit that in Rider the tool currently does not build the project and does not collect coverage.

Run configurations: the IDE runs the test and returns console output, test results and compilation errors to the agent — the "copy the terminal output back" step from #13865 disappears for anything the IDE can run.

The Debug mode documentation states the principle for the runtime case in one line: "The cause is confirmed by breakpoints, variable values, and the call stack, not just by a guess based on the code or the log." Replace "the log" with "the pasted log" and you have this article. A variable read at a breakpoint is an observation no log contains, pasted or not; an agent without a debugger is back in the relay loop for that class of bug, whatever else it can query.

Frame from the official Explyt docs video (Debug mode); different project from the one in this article. The agent sets its own breakpoints and reads the debugger, instead of asking for a pasted log.

The rest of the environment comes through the two channels any agent has. The terminal tools, per the tools reference: "The terminal tools run commands and manage processes. You need them when there is no suitable IDE configuration or when the task involves an external utility." The same page lists what to check before a command runs, because "A command can change files, a database, the environment or a remote system." This is the tool that runs psql or kubectl when you allow it.

MCP: "Once an MCP server is connected, its tools appear in the Tools menu as a separate group. The names, parameters and consequences of a call are defined by the server itself." The MCP page, in its GitHub example, suggests to "Test the connection with a safe read operation first", and notes that each MCP result block "contains the outcome and diagnostic details of the call, which are useful when verifying a result or investigating an error."

An MCP server call as it appears in the Explyt chat (Chrome MCP in the docs example). The result block keeps the outcome and diagnostics of each call in the transcript — the "record what it saw" half of the argument, for MCP. Screenshot from the Explyt documentation.

What the documentation does not describe is any built-in Kafka, SQL or Kubernetes access. Those come through the terminal or through an MCP server you connect and scope, and they land in the same session as the run configurations and the debugger, so one transcript holds the test result, the variable value and the query result side by side. And pasting remains supported: the chat documentation says large pastes become attachments and "The agent receives the complete text." Pasting should stay available as the fallback; the agent's own query should be the default.

Frame from the official Explyt docs video; different project. The agent's own reply — "Please paste the log output…" — is the relay habit this article is about. Pasting stays available as the fallback; the agent's own query should be the default.

Limits

The GitHub issues above are individual reports; I have not measured how often the relay loop occurs or how often agents with access decline to use it. Reddit threads are personal accounts with low scores. MCP server statistics are a snapshot from one day and the read-only behavior comes from the READMEs; I have not audited the servers myself. The Explyt claims are limited to what the documentation says; the session I referenced is described in the linked article and its details are not published.

One thing to try this week

Pick the next runtime bug where you would normally paste a log. Connect one read-only source the agent can query itself, a database MCP in restricted mode or the terminal with kubectl logs, and add one line to your agent instructions: state nothing about the environment without quoting the query and the result. Then read the transcript and count how many of the agent's claims come with an observation attached. I expected the count to be low the first time I did this, and it was.

If you work in a JetBrains IDE, Explyt on the Marketplace gives the agent the two sources a paste cannot replace, the IDE run and the debugger, and takes MCP servers for the rest.

What did your agent last ask you to paste that it could have fetched itself, and what happened when you gave it the access? The comments are open; I am collecting the cases where the query the human never ran turned out to be the one that mattered.

Sources

Issue reports and threads

Vendor and research

MCP servers

Explyt documentation

DEV Community