On August 25, a public OpenClaw main-branch commit removed agent-side terminal creation and added a policy-bound approval path for agent input to an existing shared terminal.
A terminal can be shared without becoming a blank cheque: an agent can work with a terminal an operator opened in the Control UI, but its ability to type is now resolved against the exact session’s execution policy and the exact live run.
The important move is not “more confirmation screens.” It is separating three facts that often get collapsed in an agent interface: a person opened the terminal, an agent can locate or read that terminal, and an agent can send a command into it. The changed terminal tool no longer offers agent-side terminal creation. It can list, read, resize, close, or enter input into an existing shared session; input is the one operation that crosses from observation and management into execution.
The permission follows the keystroke
For a session whose execution policy is deny, the new path refuses terminal input. Outside full access, it creates an approval request for the exact text the agent wants to send, requires an allow once decision, and explicitly rules out an “allow always” decision. The source then checks that the run still has its delegated authority and that the terminal manager has not changed before it writes to the PTY.
Those last checks are easy to skip in a product summary, but they make the boundary concrete. An approval is not treated as a reusable pass after the run ends; it cannot be redeemed against a terminal that vanished while the person was deciding; and a policy change is not meant to be widened merely because the agent retained a reference to an old session. The public behavior tests cover each of those cases, including two separate guarded inputs, a missing approval route, and authority loss while approval is pending.
What operators can stop assuming
For teams building agent-assisted operations, “the agent has a terminal” is too coarse a question. Ask instead: who opened it, which session owns it, what policy applies to input, who can review one proposed write, and what happens if the run or terminal changes halfway through that decision? A shared display can be useful without turning every visible shell into standing execution authority.
The source is deliberately narrower than a security guarantee. It is implementation and tests on the project’s public main branch, not evidence of a release, default configuration, or every possible gateway and terminal client. It also does not show an industry-wide policy shift; other projects have their own permission work, not a proven common standard. The next signal worth watching is public release and configuration guidance that keeps this line intact: the terminal may be shared, but the right to type remains a separate decision.