> **Up front:** I am a hobbyist, not a professional software developer. This
> report was researched and written with the help of an AI assistant while I
> was building a third-party shell plugin. I have tried to make it accurate
> and to include the evidence behind every claim, but please read the
> technical details with that in mind. If anything here is wrong or unhelpful,
> tell me and I will correct it or close it.

## What happens

A shell plugin that writes its own settings with `shell.updateEntryInline()`
never receives those settings back. `shell.json` is updated correctly on disk,
but the plugin's injected `barConfig` continues to report the previous value,
so any plugin that reacts to its own settings change never reacts.

An *external* write to the same setting, for example `omarchy bar set ...` in a
terminal, does propagate correctly. Only the plugin's own write is lost.

## Why it happens

`barConfig` is published one `shellConfig` write behind.

1. `updateEntryInline()` (shell.qml:1078) calls `persistShellConfig()` (:109),
   which assigns `shellConfig` and writes the file.
2. `onShellConfigChanged` (:67) emits `pluginsChanged()`.
3. A `Connections` block (:1052) handles it by calling `syncPluginApis()` (:861).
4. `syncPluginApis()` assigns every plugin's `shellApi.barConfig` from
   `publicBarConfig()` (:326), which reads the `barConfig` binding declared at
   :116.

A QML change handler runs *before* bindings on the same property re-evaluate,
so `publicBarConfig()` hands out the value from before the write.

An external change survives this because the user-config `FileView` re-reads
the file and produces a *second* `shellConfig` assignment, which flushes the
first. A plugin's own write produces no second assignment, because
`FileView.setText()` does not retrigger its own watcher, so the plugin never
receives the echo of its own write.

Related, and probably worth a doc line either way: `updateEntryInline()`
returns `false` when nothing changed (:1114, `if (!dirty) return false`). That
is indistinguishable from a failure at the call site, so plugins that treat
`false` as an error report a spurious failure when the value was simply already
stored.

## Steps to reproduce

1. In a plugin, call `shell.updateEntryInline(<own id>, {...changed settings})`.
2. Observe `~/.config/omarchy/shell.json` is updated correctly.
3. Observe the plugin's `settings` / `barConfig` still reports the old value,
   and keeps reporting it indefinitely.
4. From a terminal, run `omarchy bar set <id> <key> <value>` with any different
   value. The plugin now receives that change normally.

Observed with an instrumented service: a single `updateEntryInline()` call
produced 24 `settingsChanged` notifications, every one carrying the OLD value,
and a dependent action never ran within 40 seconds.

## Expected

A plugin's own settings write should reach that plugin the same way an external
write does, so a plugin can act on its own persisted state.

## Impact

Any plugin that persists a setting and then acts on it appears to do nothing.
In our case a user changed a selection in a plugin's UI, the change was written
to `shell.json` correctly, and the UI kept showing the previous selection
indefinitely, recoverable only by an external `omarchy bar set` or a shell
restart.

## Workaround, for other plugin authors

Apply your own write locally in the same turn instead of waiting for the echo,
and drop that local override as soon as the host reports any value other than
the one you wrote, so external changes still win. Keep the echo path idempotent
so a late echo is a no-op.

## System

- Omarchy 4.0.3-1
- Quickshell 0.3.1 (Arch Linux build)
- qt6-declarative 6.11.2-1
- Hyprland 0.56.2
- Kernel 7.2.3-arch1-3

Found while building a third-party shell plugin. Happy to supply a minimal
reproducer plugin if that would help.