This is a comment left during a code review.
Path: src/agents/sandbox/fs-bridge-mutation-helper.ts
Line: 91-95

Comment:
**Narrow exception catch may break atomic writes**

The `except FileNotFoundError` guard only handles the case where the file does not yet exist. Any other `OSError` (e.g., `PermissionError` with `errno.EACCES`, `OSError` on platforms where `dir_fd` is not supported for `lstat`, etc.) will propagate out of `write_atomic` and turn a previously-working write into a hard failure.

Since permission-preservation is a best-effort enhancement, all `OSError` variants should be swallowed here, mirroring the broader `except (OSError, AttributeError)` already used for `os.fchmod` a few lines below:

```suggestion
  "        try:",
  "            original_stat = os.lstat(basename, dir_fd=parent_fd)",
  "            original_mode = stat.S_IMODE(original_stat.st_mode)",
  "        except OSError:",
  "            pass  # File doesn't exist or can't be stat'd; use default permissions",
```

How can I resolve this? If you propose a fix, please make it concise.

This is a comment left during a code review.
Path: src/agents/skills/workspace.ts
Line: 214-218

Comment:
**Silent bypass makes WSL issues hard to diagnose**

When a managed skill escapes its configured root and the new bypass applies, the code returns `candidateRealPath` without any logging. The existing `warnEscapedSkillPath` call below is now unreachable for `openclaw-managed` skills, so there is no indication in the logs that the bypass was triggered.

A debug-level log entry here would help users (and future developers) confirm that the WSL-specific symlink path is the reason a skill was loaded from an unexpected real path:

```suggestion
  // Managed skills are installed to a well-known location and should not be subject
  // to path escaping checks that may fail due to symlink resolution differences (e.g., WSL)
  if (params.source === "openclaw-managed") {
    skillsLogger.debug("Managed skill path escapes root via symlink resolution; loading anyway.", {
      source: params.source,
      rootDir: params.rootDir,
      path: params.candidatePath,
      realPath: candidateRealPath,
    });
    return candidateRealPath;
  }
```

How can I resolve this? If you propose a fix, please make it concise.

This is a comment left during a code review.
Path: src/agents/skills/workspace.ts
Line: 216-224

Comment:
**Unconditional bypass applies on all platforms, not just WSL**

The exemption fires whenever `isPathInside` returns `false` for a managed skill — not only on WSL. On a standard Linux or macOS host, if the managed-skills directory (`~/.openclaw/skills`) contains a symlink that resolves outside that directory (e.g., a user or package manager created one intentionally or maliciously), the skill is now silently loaded with no warning.

Before this change the path-escaping guard would have caught and rejected that case. After this change it is silently allowed for every managed skill on every platform.

The intended fix was narrow (WSL symlink path normalisation divergence), but the implementation is unconditional. A tighter approach would be to detect whether the two paths refer to the same inode after stripping WSL drive-letter prefixes, or at minimum to emit a `warn`-level (not just `debug`) log entry when the bypass is actually triggered so operators running on non-WSL systems are aware a skill escaped its root:

```suggestion
  if (params.source === "openclaw-managed") {
    skillsLogger.warn("Managed skill resolved outside its configured root; bypassing path check (WSL symlink tolerance)", {
      source: params.source,
      rootDir: params.rootDir,
      candidatePath: params.candidatePath,
      candidateRealPath,
    });
    return candidateRealPath;
  }
```

How can I resolve this? If you propose a fix, please make it concise.

This is a comment left during a code review.
Path: extensions/feishu/src/streaming-card.ts
Line: 326-338

Comment:
**`finalText` from concurrent callers is silently discarded**

When a second `close(finalText)` call arrives while the first is still in-flight, it returns the in-flight promise and its own `finalText` argument is silently dropped. If the first call was made without a `finalText` (e.g., an internal close triggered by an error handler), and a later call carries the actual final user-facing text, that text will never be sent to the card.

This is arguably by design, but it is surprising: the API signature implies the final text will be delivered, yet in the concurrent case it is simply thrown away without any indication. At a minimum a comment on the return path should document this behaviour explicitly, or the implementation should take the latest non-null `finalText`:

```suggestion
  async close(finalText?: string): Promise<void> {
    // Prevent concurrent close calls; return existing promise if already closing.
    // NOTE: if this call carries a finalText that differs from the first call's
    // finalText, this call's finalText is intentionally discarded.
    if (!this.state) {
      return;
    }
    if (this.closePromise) {
      return this.closePromise;
    }
    this.closed = true;
    this.closePromise = this._doClose(finalText);
    return this.closePromise;
  }
```

How can I resolve this? If you propose a fix, please make it concise.