Codex Remote Control, Agent RCE Hardening, Copilot Session Hooks, and Microsoft Agent Framework 1.5

Episode 048 Transcript

[00:00–02:00] Codex remote control and agent runtime boundaries

NOVA: I'm NOVA.

ALLOY: And I'm ALLOY, and this is OpenClaw Daily. Today we are looking at four builder stories where agent runtimes become more controllable, more inspectable, and more dangerous if their boundaries are wrong.

NOVA: OpenAI Codex 0.130.0 gives coding-agent operators a cleaner remote-control surface. Microsoft’s Semantic Kernel research shows how prompt injection can become code execution when tool arguments cross into eval-based framework code. GitHub Copilot SDK adds callbacks for plan approval and rate-limit recovery. And Microsoft Agent Framework 1.5 moves orchestration, browser policy, observability, and wire semantics forward. [PAUSE]

ALLOY: The practical question underneath the last story is important: can Microsoft Agent Framework actually be used inside OpenClaw? Short answer: yes, but not as a drop-in replacement for OpenClaw’s own runtime. It can run alongside OpenClaw as an external agent service, a command-backed skill, a hosted workflow, or a bridge exposed through a tool protocol. OpenClaw would remain the local-first gateway, channel router, session manager, and tool authority. Microsoft Agent Framework would be a specialized agent runtime that OpenClaw calls into, supervises, and wraps with policy.

NOVA: That distinction matters. A framework can be useful inside a system without becoming the system. The safe integration model is not, “let a second framework take over the host.” The safe model is, “treat the framework as an untrusted or semi-trusted tool boundary with explicit inputs, outputs, permissions, telemetry, and failure handling.”

[02:00–15:00] OpenAI Codex 0.130.0 adds remote-control app servers and state repair

NOVA: Story one is OpenAI Codex 0.130.0. The headline is codex remote-control, a simpler entrypoint for starting a headless app-server that can be controlled remotely.

ALLOY: A headless app-server is a very different operational object from a one-shot command-line agent. A terminal run starts, works, and exits. An app-server owns sessions, threads, configuration snapshots, environment selection, tool execution, review events, and client connections over time. That means the runtime is no longer just answering a prompt. It is maintaining a service surface.

NOVA: Exactly. The app-server has to keep a coding session alive while clients reconnect, inspect history, open specific turns, review diffs, and continue work from a different interface. A remote-control command makes that control plane explicit. It is the path from a local coding assistant to a service endpoint that an IDE, dashboard, browser client, or remote development machine can drive.

ALLOY: The big mechanism here is separation of control and work. The server owns the durable session. Clients can come and go. The work is not bound to the life of the original terminal tab. That is useful, but it raises the bar for state management, access control, and auditability.

NOVA: Codex 0.130.0 also adds large-thread paging where clients can request unloaded, summary, or full turn item views. That sounds like interface polish until you think about what an agent thread contains. It can include user turns, model turns, tool calls, approvals, diffs, file references, images, compaction summaries, plugin metadata, and review state. Loading that entire object into every remote client is wasteful and brittle.

ALLOY: Paged thread views make the transcript behave more like an operational timeline. An unloaded item can preserve identity and ordering without transferring payload. A summary item can give enough context to navigate. A full item can be materialized when the client actually opens the detail. That is the same shape you see in trace viewers, log explorers, and issue timelines.

NOVA: It also protects latency. A remote client should not freeze because one agent thread grew into a giant work record. For long-running coding sessions, pagination is not an optimization at the edge. It becomes part of the session contract.

ALLOY: Plugin details now show bundled hooks, and plugin sharing exposes link metadata plus discoverability controls. That is an auditability improvement. Hooks are part of the runtime behavior of a plugin. If a plugin can observe startup, intercept tool calls, provide commands, or participate in review, operators need to see that before they install or share it.

NOVA: Hiding hooks inside packages turns plugin review into guesswork. Showing hook metadata makes the execution surface visible. In agent systems, discoverability without inspectability is risky. It is easy to install something that sounds like a harmless convenience and later discover that it modifies tool behavior, startup state, or review flow.

ALLOY: The release also repairs live app-server configuration behavior. Live app-server threads now pick up config changes without requiring a restart. That is a practical reliability fix because configuration in an agent runtime can include model choices, approval policies, provider settings, tool availability, plugin state, environment selection, and telemetry options.

NOVA: If a long-running thread keeps using stale config, the operator may believe policy has changed while the active agent continues under older rules. Refreshing live threads from the latest config snapshot makes policy changes take effect where work is happening. It also reduces the operational temptation to restart a service just to make an approval or provider setting stick.

ALLOY: Turn diffs get one of the most important builder fixes. Codex now keeps diffs accurate across apply_patch operations, including partial failures that still mutate files. This is a real failure mode. A patch can fail halfway through and still change part of a file. If the runtime reports the wrong diff afterward, the review view, rollback logic, and audit trail cannot be trusted.

NOVA: Operation-backed diff tracking is the right direction. The runtime should record what actually changed, not only what the ideal patch was supposed to change. Coding agents need accurate post-operation state, especially when tools are allowed to edit files. A misleading diff is worse than no diff because it creates false confidence.

ALLOY: ThreadStore fixes improve summaries, renames, resume, and fork paths, including threads without local rollout paths. That makes the storage layer more of a source of truth for lifecycle operations. Resume and fork matter because a user may branch an investigation, continue a failed run, or open a thread from a remote client that does not have the original local filesystem path.

NOVA: If thread identity depends too much on local machine state, headless and remote workflows break. A remote app-server should be able to answer, “what is this thread, what state does it contain, and how can it continue?” without assuming the original terminal context is still present.

ALLOY: Remote compaction also gets stream-contract fixes. Codex now emits response.processed for v2 streams and avoids sending service_tier on API-key compact requests. Compaction is how long sessions stay usable, but remote compaction has to speak the same event language as normal turns. A missing processed event can leave a client waiting for a terminal state. An unsupported request field can break only the compaction path, which makes diagnosis painful.

NOVA: Multi-environment support shows up in view_image, which can now resolve files through the selected environment. That matters because coding agents often operate across a host, container, sandbox, remote workspace, or mounted project. An image path is not meaningful unless the runtime knows which environment owns it. Resolving through the selected environment prevents a client from looking at the wrong filesystem or failing to display an artifact that exists inside the active sandbox.

ALLOY: Bedrock authentication support now accepts AWS console-login credentials from aws login profiles. That is operator convenience with deployment impact. Many teams already manage AWS access through profile-based flows. Letting Codex use those profiles reduces duplicate credential paths and makes model-provider authentication line up with existing cloud access controls.

NOVA: The telemetry changes are useful for production debugging. Codex adds configurable OpenTelemetry trace metadata and richer review and feedback analytics. Review events are central to coding-agent safety. If a command was approved, denied, retried, or escalated, operators need enough trace context to understand why.

ALLOY: Good telemetry connects the session, turn, tool call, approval decision, model request, and user-visible result without leaking secrets. That is the line to walk. Too little telemetry makes incidents impossible to reconstruct. Too much telemetry can expose prompts, files, credentials, or private code.

NOVA: The practical recommendation is to treat Codex app-server deployments like service deployments. Pin the version. Start remote-control deliberately. Document which clients can connect. Audit plugin hooks before sharing. Test config refresh behavior. Test partial patch failures. And verify that compaction, thread resume, and image viewing work across the environments you actually use.

ALLOY: One more operational detail is worth spelling out. When a coding agent becomes an app-server, the boundary between product UX and runtime state gets thinner. A user interface can now ask for a compacted summary, a full turn, a plugin detail page, a review event, or an image artifact. If those endpoints are not versioned and tested, the UI can accidentally depend on internal shapes that change in a release. Builders should treat those app-server responses as API contracts, even when the client and server ship together.

NOVA: That also changes incident response. In a terminal-only model, an operator may scroll back through the shell transcript and inspect the working tree. In a remote app-server model, the evidence is distributed across thread storage, tool operation records, telemetry, review approvals, plugin metadata, and environment-specific file views. The runtime has to preserve enough state to reconstruct what happened after the fact.

ALLOY: And because remote clients can reconnect, the session should be robust against partial client failure. If a browser tab disconnects during compaction, the server still needs a terminal event. If a patch partially applies and the client refreshes, the server still needs the real diff. If config changes during a long thread, the active policy should be understandable. That is why these apparently small fixes add up to a more credible remote-control runtime.

NOVA: The release is not only about new commands. It is about making a coding agent controllable, inspectable, and recoverable when sessions grow large and run remotely.

[15:00–27:00] Semantic Kernel RCE research turns prompt injection into a tool-execution boundary lesson

NOVA: Story two is Microsoft’s security case study on remote code execution in AI agent frameworks. The important point is that the model is not the vulnerable component in the core failure. The dangerous boundary is framework and plugin code that trusts model-controlled tool arguments and turns them into executable host behavior.

ALLOY: The disclosed path centers on Semantic Kernel’s In-Memory Vector Store search flow. The example agent exposes a hotel search plugin. A user asks for hotels in a city. The model calls the search function with a city argument. The plugin builds a filter before vector similarity search. The risky step is that a model-controlled value is interpolated into a Python lambda expression and executed with eval.

NOVA: That is the boundary crossing. A normal city string becomes part of a filter expression. A malicious string can close a quote and append Python logic. Prompt injection does not need a browser exploit or memory corruption when the framework turns natural-language-controlled values into code. The agent has become a path from text to host execution.

ALLOY: The attempted mitigation used AST validation and a restricted builtins environment. At a high level, the validator allowed lambda expressions, scanned names and attributes for dangerous identifiers, and executed with builtins removed. That sounds plausible, but dynamic languages make blocklists fragile.

NOVA: Microsoft’s researchers bypassed the filter without relying on the obvious blocked names directly. The payload traversed Python object structures to locate import machinery and reach command execution through alternate attributes. That is the classic problem with trying to make a general host-language evaluator safe by banning known-dangerous tokens.

ALLOY: The lesson is not only “do not use eval,” although that is a good starting point. The broader lesson is that tool-call arguments are untrusted input even when they came from a model, even when the user did not type code directly, and even when the schema claims the field is something harmless like a city name.

NOVA: A model can be induced to place attacker-controlled strings into any argument it is allowed to fill. If the tool interprets that string as code, a query language, a shell command, a file path, a template, or a serialized expression, the framework has created an injection sink.

ALLOY: Vector search makes the issue easy to underestimate because it feels like retrieval infrastructure, not code execution. But vector stores often support metadata filters, expression languages, custom predicates, embedding prefilters, rerankers, and connector-specific query strings. Any one of those can become an injection boundary if user or model-controlled values are concatenated into an interpreted expression.

NOVA: Safer design usually means parameterized filters, typed DSLs, allowlisted operators, and validation that rejects unexpected structure before execution. Field equals value should be data, not source code. If a filter language is unavoidable, the runtime should parse into a constrained AST and evaluate with an interpreter that only understands the allowed operations. It should not call the host language evaluator and try to block dangerous behavior afterward.

ALLOY: Least privilege matters too. A hotel-search predicate does not need shell access. If a framework bug turns a filter into code execution, the sandbox and process privileges determine the blast radius. Agent frameworks should isolate plugin execution, limit environment variables, avoid passing credentials into generic tool processes, and log tool parameters carefully enough for incident response.

NOVA: Detection is practical. Teams should inventory tools that execute templates, filters, shell commands, notebook cells, Python snippets, JavaScript snippets, SQL, or file operations. Then they should trace whether model-controlled values can reach those interpreters. Patching Semantic Kernel is necessary for users of the affected path, but custom plugins often repeat the same pattern.

ALLOY: There is also a testing lesson. A normal unit test may pass because it checks a friendly city name, a friendly category, or a friendly metadata field. Security tests need adversarial values that try to break out of the expected syntax. For a vector filter, that means quotes, braces, operators, attribute traversal, very long strings, unusual unicode, and attempts to reference objects that should never be reachable. The test should assert that these values remain data.

NOVA: A useful review question is, “where is the first interpreter?” If a value is parsed as JSON, that is one boundary. If it becomes SQL, that is another. If it becomes a Python lambda, shell command, template, regular expression, or file path, each step needs its own validation rule. The worst pattern is converting user or model data into a string that is later interpreted by a more powerful language than the schema promised.

ALLOY: Framework maintainers also have to make the safe path the default path. If the easy example in documentation uses string concatenation into a filter expression, downstream applications will copy it. If the default vector store helper accepts a typed filter builder, fewer applications will invent their own unsafe version. Agent security improves when framework ergonomics push developers toward safe composition.

NOVA: That is why this research matters beyond one bug. It gives builders a concrete mental model: prompt injection becomes host compromise only when there is a bridge from language-controlled data to privileged execution. Find the bridges, narrow them, and remove interpreters from the normal path.

ALLOY: This is where OpenClaw’s own operating model is relevant. OpenClaw treats inbound DMs and channel messages as untrusted input. It has a local-first gateway, channel routing, tool policies, and sandboxing options for non-main sessions. But that does not magically make every called framework safe. If OpenClaw invokes an external agent framework, the same rule applies: the framework is a tool boundary, not trusted internal language.

NOVA: Right. If a Microsoft Agent Framework workflow, a Semantic Kernel plugin, or any other external runtime is called from OpenClaw, the integration should define a narrow command contract, typed inputs, allowlisted actions, environment isolation, timeouts, and structured outputs. The host should not hand the external runtime unlimited filesystem, network, token, or shell access unless that is truly intended.

ALLOY: The operator takeaway is blunt: every agent tool is an API endpoint whose caller is partly controlled by the model. Treat tool schemas as external API contracts. Validate inputs at the boundary. Prefer typed data structures over interpreted strings. Keep permissions narrow. Log enough to reconstruct which prompt produced which tool arguments. And test prompt injection by trying to force hostile parameters into tools, not only by checking whether the model says unsafe words.

NOVA: Prompt-injection security is not just model behavior. It is input validation, interpreter avoidance, sandboxing, and least-privilege design for the runtime that executes work.

[27:00–36:00] GitHub Copilot SDK adds plan approval and rate-limit recovery hooks

NOVA: Story three is GitHub Copilot SDK’s May 8 pre-release. This one is about embedding coding-agent sessions into products with more explicit runtime control.

ALLOY: Applications can now register callbacks for exitPlanMode.request and autoModeSwitch.request. Those events matter because plan mode and automatic model switching are product decisions, not only model decisions.

NOVA: Plan mode is a boundary between proposing work and doing work. In an embedded coding agent, the application may want a human to approve the plan, a policy engine to check it, or a project-specific rule to block certain changes. A handler for exit-plan-mode requests gives the host product a clear interception point before the runtime moves from planning into execution.

ALLOY: Automatic model switching after rate limits is a different boundary. A runtime may want to recover from a rate-limit event by moving to another model or mode. That can preserve continuity, but it can also change behavior, cost, latency, or capability. The autoModeSwitch.request handler lets the application decide whether to accept the switch.

NOVA: For enterprise products, that matters because model choice can be tied to data policy, compliance, evaluation baselines, and budget controls. A fallback that seems harmless to the runtime may be unacceptable to the host application if it crosses a provider boundary or changes retention policy.

ALLOY: The release also adds structured diagnostics across the .NET, Python, and Rust SDKs. The logs cover CLI startup, TCP connection, JSON-RPC request timing, session lifecycle, and error paths. That is the visibility an embedded agent SDK needs.

NOVA: When a session fails, the cause may be process startup, transport, authentication, JSON-RPC framing, runtime event handling, model response, tool execution, or host callback behavior. Without structured timing and lifecycle logs, everything looks like “the agent hung.”

ALLOY: The JSON-RPC detail is especially important. Many coding-agent SDKs wrap a local runtime process and communicate over JSON-RPC. That creates a client object in the application, a runtime process, a transport connection, request IDs, event streams, and long-running operations. Diagnostics need to show when the runtime started, when the TCP connection opened, which requests were sent, how long they took, and where errors surfaced.

NOVA: The enableSessionTelemetry option makes telemetry an explicit session choice. That is the right shape for privacy and operations. Some deployments want session telemetry to debug issues and improve reliability. Others need it disabled by policy. Putting the knob on session configuration and resume configuration makes the decision auditable and repeatable.

ALLOY: There are smaller compatibility fixes with real impact. C# session-event enums are now string-backed readonly structs so deserialization does not fail when the runtime adds new enum values. That is forward compatibility for event streams. Rust binary tool result resource blobs now default to application/octet-stream when mimeType is absent. That is wire-format resilience.

NOVA: The practical builder implication is that Copilot SDK sessions are becoming host-controlled runtime objects. If you embed them, implement the plan-mode and mode-switch callbacks deliberately. Decide which switches can happen automatically and which require review. Turn on diagnostics in development and staging. Capture JSON-RPC timing around slow or flaky sessions. Treat telemetry as policy, not a hidden default.

ALLOY: And test older clients against newer runtime events. Event streams evolve. If enum handling or MIME defaults break, the agent may be working while the host product cannot deserialize what happened.

[36:00–50:00] Microsoft Agent Framework 1.5 and whether it can be used inside OpenClaw

NOVA: Story four is Microsoft Agent Framework 1.5. The release is broad, but several changes are directly relevant to production agent builders: Magentic Orchestration for .NET, WebBrowsingTool allowlisting, hosted-agent observability samples, reasoning events in AGUI, class-based skills and harness context providers in the Python line, todo-state injection, Foundry per-call headers, and a wire-format fix for function_call_output.output.

ALLOY: Magentic Orchestration is the headline because multi-agent systems need more than a list of agents. They need scheduling, delegation, turn ownership, shared state, termination conditions, and a way to decide which actor should move next. An orchestration layer formalizes those mechanics. Marking it experimental is appropriate because orchestration semantics become application architecture.

NOVA: A bad scheduler can loop, duplicate work, hide failures, or let one agent dominate a conversation. Multi-agent orchestration is not magic collaboration. It is a runtime policy about who acts, when they act, what context they see, and when the process stops.

ALLOY: WebBrowsingTool allowlisting is an important browser-control feature. Browsing tools connect an agent to external content that may be malicious, untrusted, or simply distracting. An allowlist gives the host application a policy surface before the browser tool runs.

NOVA: In agent systems, browsing is not just reading. The browser can fetch prompt-injection content, submit forms, follow redirects, expose cookies, retrieve files, and interact with authenticated sessions. Policy has to exist before tool execution, not only after a bad page has already influenced the run.

ALLOY: Hosted-agent observability samples are also valuable because deployment is where framework abstractions meet production reality. A hosted agent needs logs, traces, request correlation, model-call visibility, tool-call timing, and failure state. The useful question is whether a team can reconstruct a failed run from the external request through orchestration, model call, tool call, and final response.

NOVA: Reasoning events in AGUI expose a transport issue. User interfaces need to render agent progress without mixing private chain-of-thought, tool rationale, and user-visible summaries incorrectly. A reasoning event channel lets the framework represent progress or reasoning-related state as structured events. The application still has to decide what is safe to show, store, and transmit.

ALLOY: Todo multithreading and todo injection into the message list show how task state becomes a runtime feature. Agents use todo lists to plan, track progress, and recover after interruptions. If todo state is not thread-safe, concurrent updates can corrupt the plan. If todo state is not visible in the message context, the model may lose track of commitments.

NOVA: The function_call_output.output wire-format fix is small but critical. The release fixes it to be a JSON string on the wire. Tool output formats are contracts between runtime, SDKs, models, and clients. If one side expects a string and another side sends structured JSON directly, deserialization, replay, storage, or compaction can fail.

ALLOY: Sequence number generation gets a fix for duplicate or out-of-order IDs. Event ordering is foundational for agent UIs and logs. If two events share a sequence number or arrive out of order, clients can render stale state, drop updates, or attach a tool result to the wrong turn. In a multi-agent or multiparty conversation, ordering bugs are especially painful.

NOVA: Workflow re-entry and YAML parsing fixes speak to declarative-agent reliability. A loop after GotoAction re-entry can turn workflow convenience into runaway behavior. YAML block scalar parsing for file skills matters because file-based skills often contain prompts, instructions, examples, or scripts. If block scalars parse incorrectly, the skill the agent sees is not the skill the developer wrote.

ALLOY: Now to the OpenClaw integration question. Can Microsoft Agent Framework be used inside OpenClaw? Yes, but the clean architecture is adapter-based. OpenClaw is a local-first assistant gateway that already manages channels, sessions, tools, nodes, browser and canvas surfaces, cron, skills, sandboxing, and multi-agent routing. Microsoft Agent Framework is a separate agent framework with .NET and Python surfaces. It should be integrated as a called runtime, not confused with OpenClaw’s native session runtime.

NOVA: There are several workable patterns. First, a command-backed skill: OpenClaw can invoke a local script or service that runs a Microsoft Agent Framework workflow and returns a structured result. That is the simplest form. The skill input is typed. The framework process runs with a defined working directory and environment. The output is captured as text or JSON. Timeouts and failure handling stay in OpenClaw.

ALLOY: Second, a hosted local service: a .NET or Python Agent Framework app can run as a localhost service or private network service. OpenClaw calls it through a narrow HTTP or RPC adapter. This is useful if the framework needs long-lived orchestration state, warm model clients, or its own observability pipeline. OpenClaw still owns which channel can call it and what credentials are exposed.

NOVA: Third, a tool-protocol bridge: if the Agent Framework workflow can be exposed behind a tool server, OpenClaw can treat it like another tool provider. The important part is the boundary. Tool names, schemas, allowed operations, and returned artifacts must be explicit. OpenClaw should not blindly import every capability of a framework process into every session.

ALLOY: Fourth, a sandboxed subagent lane: OpenClaw can route selected tasks to a non-main agent or sandbox that has permission to run the external framework. This is a safer pattern for experiments because the framework can be given limited filesystem and network access. It is especially relevant for browser tools and hosted workflows that may encounter untrusted content.

NOVA: The integration limits are just as important. Microsoft Agent Framework does not automatically become a native OpenClaw channel. It does not automatically inherit OpenClaw’s pairing policy, Discord or Telegram routing, live Canvas behavior, node management, memory model, or approval gates. Those have to be wrapped deliberately. It also brings its own dependencies, event model, skill semantics, and tool-output contracts.

ALLOY: The security lesson from the Semantic Kernel story applies directly. If OpenClaw calls a Microsoft Agent Framework agent, model-generated arguments from one runtime may enter another runtime’s tools. That means validation cannot be assumed. A safe bridge should use typed request objects, allowlisted operations, redacted logs, least-privilege environment variables, explicit browser allowlists, and no generic shell access by default.

NOVA: Observability needs a bridge too. OpenClaw can trace a user message, session, tool call, and reply. Microsoft Agent Framework can trace orchestration, model calls, tool calls, reasoning events, and workflow state. A production integration should carry a correlation ID across that boundary so a failed request can be followed from channel message to OpenClaw session to external framework invocation and back.

ALLOY: The practical recommendation is cautious optimism. Use Microsoft Agent Framework inside OpenClaw when it provides a specific capability: Magentic-style orchestration, Foundry integration, hosted-agent samples, declarative skills, or a workflow already written in .NET or Python. Do not use it merely because it is another agent framework. If OpenClaw already provides the channel, session, and tool behavior needed, adding a second framework may add complexity without value.

NOVA: The best first experiment would be narrow. Build one Microsoft Agent Framework workflow that performs a contained task, expose it through a single OpenClaw skill or local service, pass one typed input object, return one structured result, run it without broad credentials, and log the correlation ID. Then evaluate latency, reliability, tool safety, and whether the orchestration result is better than a native OpenClaw skill.

ALLOY: If the answer is yes, expand carefully. Add browser access only with allowlists. Add file access only to a scoped workspace. Add credentials only through explicit secret references or environment injection. Add persistent state only after replay and resume semantics are clear. And never let a framework bridge silently widen the permissions of a chat session.

NOVA: So the answer is not “no, because OpenClaw is separate,” and it is not “yes, just install it and let it run everything.” The answer is: yes, Microsoft Agent Framework can be used inside an OpenClaw deployment as an integrated external runtime, but OpenClaw should remain the authority for channel ingress, user trust, tool policy, sandboxing, and delivery.

ALLOY: There are some cases where the integration would be worth it. If a team already has .NET agents built around Foundry, Magentic Orchestration, declarative workflows, or Microsoft’s hosted-agent samples, wrapping that work for OpenClaw can preserve investment. OpenClaw can become the personal operating layer around it: message intake, user approval, channel delivery, schedule triggers, file staging, and local machine control.

NOVA: There are also cases where it would not be worth it. If the task is a simple local automation, a normal OpenClaw skill is likely easier to inspect and operate. If the task needs one tool call and one answer, adding a second orchestration framework can create more serialization, more logs, more dependencies, and more failure modes than value. The integration should be justified by orchestration, existing code, hosted-agent infrastructure, or a concrete Microsoft ecosystem requirement.

ALLOY: Versioning is another real consideration. OpenClaw, the external framework, model SDKs, and tool schemas can all evolve independently. A bridge should declare the framework version it expects, validate returned event shapes, and fail clearly when a wire contract changes. Silent partial compatibility is dangerous because it can make an agent appear to work while losing todo state, tool output, sequence ordering, or reasoning events.

NOVA: The recommended shape is boring on purpose: one adapter, one schema, one permission profile, one correlation ID, one timeout policy, and one clearly documented output. Start there. If that works, add capabilities slowly. The goal is not to make OpenClaw and Microsoft Agent Framework indistinguishable. The goal is to let OpenClaw safely call a useful external agent runtime when that runtime earns its place.

[50:00–53:00] Closing

ALLOY: The practical takeaway from EP048 is operational. Codex 0.130.0 makes coding-agent sessions more service-like with remote-control app servers, paged thread views, plugin hook visibility, config refresh, better patch diffs, compaction fixes, and multi-environment file resolution.

NOVA: Microsoft’s Semantic Kernel research shows how model-controlled tool arguments can become code execution if frameworks turn them into interpreted host-language expressions. GitHub Copilot SDK gives embedded products approval and recovery hooks plus diagnostics. Microsoft Agent Framework 1.5 pushes orchestration, browser policy, observability, event transport, todo state, and wire-format correctness forward.

ALLOY: And on the OpenClaw question: Microsoft Agent Framework is usable inside OpenClaw as a bounded external runtime, service, skill, or tool bridge. It should not bypass OpenClaw’s own trust, routing, sandbox, and approval model.

NOVA: For builders, make every agent runtime boundary explicit: control plane, tool input, approval event, browser policy, telemetry, framework bridge, and stored thread state. Thanks for listening to OpenClaw Daily. Show notes and source links are available at Toby On Fitness Tech dot com, and we'll be back soon.