Entering text in web page fields.

[hearty pewter]

Question: What's the correct syntax to input text into a focused element using browser control that doesnt get tripped up? Is there documentation for the write subcommand?

[steel violet]

To help others find answers, you can mark your question as solved via Right click solution message -> Apps -> ✅ Mark Solution

[whole spruce]

Use a snapshot ref, not just the currently focused element.

There is no write subcommand in current OpenClaw docs/CLI. The ones you want are:

openclaw browser snapshot --interactive
openclaw browser type e12 "hello"

Or, if typing gets flaky, use fill instead:

openclaw browser fill --fields '[{"ref":"e12","value":"hello"}]'

A few gotchas:

• actions are ref-based, not focus-based
• CSS selectors are not supported for actions
• refs can change after navigation, so re-run snapshot if needed
• on user / existing-session, type --slowly is not supported, so fill is often safer

Docs:

• https://docs.openclaw.ai/cli/browser
• https://docs.openclaw.ai/tools/browser

If your local CLI shows different commands, paste openclaw --version and openclaw browser --help.

[hearty pewter]

what causes sigkills and sessions to be unstable?

[whole spruce]

First thing, what does openclaw --version show?

In general, a SIGKILL means the process was hard-killed from outside, not that it exited cleanly. Common causes:

• OOM / memory pressure. If you see exit 137, that is the classic one.
• exec/harness timeout or cleanup
• container / VM / supervisor restart
• sandbox/policy kill

For the two system messages above, I would not treat that as “browser sessions are unstable” by itself. Those were --help commands that printed output, then the exec runner reaped them. That looks more like tool-runner cleanup than browser-control failure.

If you are seeing real instability on your own setup, please paste:

openclaw --version
openclaw status --all

openclaw gateway status
openclaw logs --follow

And if you're on a small VPS / container, definitely check RAM, because SIGKILL + flaky sessions is very often OOM.

Docs:

• https://docs.openclaw.ai/help/faq
• https://docs.openclaw.ai/gateway/troubleshooting

[hearty pewter]

openclaw --version
OpenClaw 2026.4.15 (041266a)

on a m1 16gb ram

[whole spruce]

Cool, 2026.4.15 is recent enough, so this probably is not just “old version weirdness.”

If the only SIGKILLs you saw were those Discord system messages, I’d mostly ignore them. That looked like the exec runner cleaning up helper commands, not browser control exploding.

If the browser session itself is unstable, next please paste:

openclaw status --all
openclaw browser status
openclaw browser profiles

And tell me which profile you’re using:

• openclaw (managed browser)
• user / existing-session
• remote CDP / node host

Also, if logs show exit 137 or plain Killed, that’s usually OOM.

If you want, paste those 3 outputs and I’ll help narrow it down.

Yeah, on an M1 with 16 GB RAM, I would not blame memory first, unless you’re also running a hungry local model stack.

So I’d look at these instead:

• user / existing-session profile being flaky
• gateway or browser restarts
• exec runner noise rather than a real browser crash
• macOS-specific process weirdness

If you’re using the managed openclaw profile, that is usually steadier than attaching to your live browser.

Can you paste:

openclaw browser status
openclaw browser profiles

openclaw status --all

And tell me whether you’re using:

• openclaw
• user
• custom remote CDP

If you’re on user, I’d also try this once:

openclaw browser --browser-profile openclaw start
openclaw browser --browser-profile openclaw tabs