Funny how the "miracle of LLMs and AI" makes debugging and troubleshooting worse.
With fewer people documenting their struggles on platforms
like Stackoverflow and online spaces – the slop-machines are
hallucinating potential fixes and often failing.
A human operator gets stuck in prompt and debug hell, struggling to learn the simple correct way of doing things.
Meanwhile opensource maintainers have their hands full with LLM PRs and
vulnerabilities so documentation and human usability falls to the wayside.
Anyway rant over…now to the topic at hand:
TL;DR: Fix: allow access to /tmp/.X11-unix and read access to $XAUTHORITY
How to copy and paste from the opencode harness from inside a nono sandbox.
In other words how to allow the agent access to the clipboard from
within the nono sandbox.
So let’s try understand what is going on
- How does copy-paste work on a normal terminal on ubuntu 24.04
desktop - Will a nono sandbox bash shell prevent copy and paste? How to make
it work? - Will a nono sandbox running opencode prevent copy and paste? Is
there any difference?
I will not outsource the thinking to llms in this case as it does not
work – best to research with the llm but think clearly about a
solution without it. I have tried for a few days with no luck using
the slop machines.
How does copy and paste work on normal terminal on ubuntu 24.04 desktop
- A computer makes use of temporarily saving selected data into a
hidden memory space called the clipboard - The clipboard is part of userspace. The kernel just provides
transport and storage via system calls. (On windows it is part of the
kernel so sometimes there is confusion) - Userspace provides:
- who owns clipboard
- format conversion
- permissions over what can copy and paste
There are many variations between OSes and window managers/communication
protocols. You might need years to figure out what is going on but from
what I can see there is X11 (Xorg) and Wayland – Wayland is the more
recent tech and there is a move towards it by the community.
Seems very complicated.
Moving on…
Will a nono sandbox bash shell prevent copy and paste? (On Wayland)
Sandboxes blocks clipboard access by design…the display socket it
blocked.
nono rungrants only workdir by default
nono run bash
bash-5.2$ nono why --self --path /run/user/1000/wayland-0 --op readwrite
DENIED Reason: path_not_granted Details: Path is not covered by any
capability: /run/user/1000/wayland-0 Suggested fix: --allow-file
/run/user/1000/wayland-0
However as I am using the sandbox locally – I would like to copy from it
and paste to it.
What is interesting is that running bash – a Ctrl + Shift + C does
copy and one can paste elsewhere. This is due to the terminal emulator
handles the copying which is outside nono.
It copies its own scrollback to the host Wayland clipboard using its
own unsandboxed connection. nono doesn’t block that.
Running the copy with the wayland socket fails, as the copy is being
done by the sandboxed process:
bash-5.2$ wl-copy <<< "foo"
Failed to open temp file: Permission denied
bash-5.2$ wl-paste
wl-paste
Fix with allow /tmp
nono run --allow /tmp -- bash
bash-5.2$ wl-copy hello
bash-5.2$ wl-paste
hello
Apparently if
af_unix_mediationis on - then explicit access to the
wayland display socket is needed
Will a nono sandbox running opencode prevent copy and paste?
Some notes picked up by the DeepSeek V4 Pro slop machine - use info at your own risk:
- Opencode's terminal UI is build with OpenTUI which owns the clipboard
- OpenTUI writes to two places (great thanks...) the host clipboard and the terminal clipboard (OSC52).
- On Linux the host clipboard tries Wayland first and then falls back to X11/WWayland (what is XWayland...I don't know...a merge of the 2?)
- The wayland mutter clipboard path is not usable by a headless CLI so OpenTUI ends up on X11 - which the fix is based on.
- The
nonosandbox blocks the X11 socket and cookie so copying fails. - Fix: grant
/tmp/.X11-unixand read access to$XAUTHORITY
Trying:
nono run --profile nolabs-ai/opencode --allow /tmp -- opencode --standalone
Did not work. The terminal emulator's clipboard is unavailable from
opencode.
Opencode automatically copies anything selected. It says "Copied to
clipboard" however in the inputbox it says
Authorization required, but no authorization protocol specified.
The copy fails.
That auth error is X11, not Wayland according to LLM
The issue was that Opencode uses OSC52 plus a native backend that needs
Xauth
The fix
Bottomline is opencode clipboard is X11-first, not Wayland.
Verified by the
docs,
a env variable is needed to launch wayland first OC_ALLOW_WAYLAND=1.
So it needs the following:
nono run --profile nolabs-ai/opencode --allow /tmp/.X11-unix --read-file "$XAUTHORITY" -- opencode --standalone
That should allow copying and pasting.
You can add to your nono profile with:
"filesystem": {
"allow": [
"/tmp/.X11-unix"
],
"deny": [],
"write": [],
"allow_file": [],
"write_file": [],
"read_file": ["$XAUTHORITY"],
}
Conclusion
Be very careful, slop machines will claim that all you need to do is allow wayland socket access....but it did not work for me and probably won't for you.
Opencode v2 uses X11 by default on linux.
Opencode via nono needs read access to the X11 cookie - a secret - for
connection between X11 and wayland or so CLI tools can authenticate with
your X11 display server. One of those options.
/tmp/.X11-unix holds unix domain sockets to communicate with X11
display server - opencode uses those sockets to communicate the cope and
pastes contents.
Learnt a little bit today.
